Kurzfassung
Gleich sechs kritische Schwachstellen betreffen Apache Artemis, Apache ActiveMQ Artemis, Apache FreeMarker und Apache Camel K. Für Betreiber ist das vor allem dann relevant, wenn die Systeme im Cluster-, Template- oder Kubernetes-Umfeld laufen. Die gefährlichsten Punkte: unautorisierter Zugriff auf Sitzung oder Cluster-Zugangsdaten, Löschen von Queues vor der Authentifizierung sowie Code- und Objekt-Injection in Camel K.
Wer eines dieser Produkte produktiv einsetzt, sollte die Versionen jetzt gegenprüfen. Für Artemis nennt der Hersteller 2.57.0 als Fix. FreeMarker ist ab 2.3.35 bereinigt. Bei Camel K liegen die korrigierten Stände bei 2.9.3, 2.10.2 und 2.11.0, je nach Branch.
Was ist passiert?
Die NVD listet mehrere CVEs mit kritischem Schweregrad, die sich auf zwei Apache-Projekte und deren Einsatz in typischen Enterprise-Setups verteilen. Bei Apache Artemis und Apache ActiveMQ Artemis geht es um Angriffe auf das Messaging-Subsystem. Ein Angreifer in Reichweite des Netzes kann bei CVE-2026-49364 während des ersten Cluster-Handshakes administrative Zugangsdaten abgreifen. CVE-2026-57967 erlaubt einem unauthentifizierten Remote-Angreifer, eine bestehende Sitzung zu übernehmen. CVE-2026-67593 betrifft den OpenWire-Pfad und kann dazu führen, dass eine Queue gelöscht wird.
Apache FreeMarker ist von CVE-2026-84939 betroffen. Hier führt eine Path-Traversal-Schwachstelle im Template-Loading dazu, dass ein manipuliertes Locale-Element den Lookup-Pfad beeinflussen kann, sofern die lokale Suche aktiviert ist. Das ist laut Beschreibung standardmäßig der Fall. Bei Apache Camel K melden die Einträge CVE-2026-80351 und CVE-2026-80352 Probleme bei der Verarbeitung von dynamisch ausgewertetem Code beziehungsweise YAML. In beiden Fällen kann ein Angreifer über die jeweilige Konfiguration Code oder Kubernetes-Objekte einschleusen.
Technische Details
CVE-2026-49364 und CVE-2026-57967 treffen Artemis im Bereich der Protokoll- und Cluster-Logik. Das ist heikel, weil solche Schwächen oft vor jeder eigentlichen Geschäftslogik wirken. Wer dort kompromittiert wird, verliert Kontrolle früh im Verbindungsaufbau oder mitten in einer laufenden Sitzung. CVE-2026-67593 setzt am OpenWire-Protokoll an und kann Queue-Inhalte oder Warteschlangenstrukturen zerstören. Das ist kein reines Verfügbarkeitsproblem, sondern kann Messaging-Flows und nachgelagerte Prozesse aus dem Tritt bringen.
Bei CVE-2026-84939 liegt das Problem im Template-Lookup. Die Schwachstelle bleibt laut Beschreibung zwar durch den verwendeten TemplateLoader begrenzt, aber das ist kein Entwarnungssignal. In Umgebungen mit FileTemplateLoader schützt die Basisverzeichnis-Grenze, andere Loader können jedoch mehr Zugriff zulassen. Für CVE-2026-80351 reicht tenant-gesteuerter Inhalt in einer dynamisch ausgewerteten Maven-Konfiguration, um Code im Operator-Pod auszuführen. CVE-2026-80352 dreht sich um eine YAML-Injection in der Custom-Resource-Konfiguration. Dort kann ein berechtigter CR-Autor Kubernetes-Objekte einschleusen und über die Operator-Rechte handeln.
Wer ist betroffen?
Betroffen sind Apache Artemis 2.50.0 bis 2.56.0 sowie Apache ActiveMQ Artemis 1.0.0 bis 2.44.0. Für diese beiden Linien nennt die Quelle jeweils denselben Fixstand. Das bedeutet: Wer ältere, aber noch produktive Broker-Installationen betreibt, sollte die Versionen sofort abgleichen. Gerade in DACH-Unternehmen finden sich solche Systeme oft in Integrationsschichten, Fachanwendungen und internen Messaging-Ketten. Sie laufen selten im Rampenlicht, sind aber geschäftskritisch.
Apache FreeMarker ist von 2.2.0 bis 2.3.34 betroffen. Das ist für Java-Anwendungen relevant, in denen Templates zur Laufzeit geladen werden. Apache Camel K trifft es von 2.0.0 bis vor 2.9.3 sowie von 2.10.1 bis vor 2.10.2. Wer Camel K im Kubernetes-Umfeld nutzt, sollte besonders auf Operator-Rechte, Mandantentrennung und die Herkunft von Repository-Inhalten achten. Für Privatanwender ist die Relevanz gering; diese Produkte laufen fast nur in Unternehmensumgebungen.
Empfohlene Maßnahmen
Die erste Maßnahme ist banal und trotzdem die wichtigste: Versionen prüfen. Bei Artemis und ActiveMQ Artemis auf 2.57.0 gehen. Bei FreeMarker auf 2.3.35 aktualisieren. Bei Camel K die jeweils passende korrigierte Version einsetzen: 2.9.3, 2.10.2 oder 2.11.0. Wer seine Plattform noch nicht direkt patchen kann, sollte die betroffenen Dienste aus dem Netz nehmen oder zumindest den Zugriff eng begrenzen.
Für FreeMarker hilft in älteren Ständen das Abschalten der localized lookup-Funktion. Das ist kein Ersatz für das Update, kann aber als Übergang dienen. Bei Artemis lohnt ein Blick auf Cluster-Verbindungen, offene Broker-Endpunkte und die Frage, ob wirklich alle Protokolle gebraucht werden. OpenWire und CORE sollten nur dort aktiv sein, wo sie fachlich nötig sind. In Camel K sollten Admins die Operator-Rechte, die Mandantenmodelle und die Herkunft von Maven-Repository-Inhalten prüfen. Wenn Tenants Repository-Inhalte steuern können, gehört das sofort in die Risikoanalyse.
Offizielle Details und Fixstände finden sich in den NVD-Einträgen zu den CVEs. Da hier keine Hersteller-Advisories mitgegeben wurden, bleiben die NVD-Seiten die belastbare Referenz für die Zuordnung der betroffenen Versionen.
Einschätzung von CyberSecurity-News.de
Die Lage ist ernst, aber nicht für jeden Leser gleich kritisch. Wer eines der betroffenen Projekte im Backend, im Cluster oder im Kubernetes-Operator betreibt, hat ein echtes Problem und sollte nicht auf den nächsten regulären Wartungstermin warten. Besonders unangenehm: Mehrere der Schwachstellen greifen vor oder während der Authentifizierung an. Das macht klassische Schutzannahmen schnell wertlos.
Die Informationslage ist allerdings noch dünn genug, dass man keine großen Geschichten daraus machen sollte. Es fehlen hier etwa belastbare Angaben zu aktiver Ausnutzung oder zu verfügbaren Workarounds jenseits des Upgrades. Genau deshalb ist nüchternes Handeln gefragt. Wer Artemis, FreeMarker oder Camel K einsetzt, prüft jetzt die eigene Version, plant das Update und reduziert bis dahin die Angriffsfläche. Mehr braucht es im Moment nicht, aber weniger wäre fahrlässig.
Fazit
Sechs kritische CVEs, drei Produktgruppen, ein klarer Auftrag: prüfen, patchen, absichern. Artemis und ActiveMQ Artemis sollten auf 2.57.0 gebracht werden. FreeMarker gehört auf 2.3.35. Für Camel K sind die korrigierten Versionen je nach Branch 2.9.3, 2.10.2 oder 2.11.0. Wer diese Software in Produktion betreibt, sollte den Patchday vorziehen.
