Apache ActiveMQ unter aktivem Beschuss: Was Security-Teams aus den 6.364 offenen Instanzen am 19.04.2026 lernen müssen

8 Min. Lesezeit · Stand: 21.04.2026

Die Shadowserver Foundation hat am 19.04.2026 bei einem internetweiten Scan 6.364 öffentlich erreichbare Apache-ActiveMQ-Instanzen identifiziert, die über CVE-2026-34197 ausnutzbar sind. Die CISA-Known-Exploited-Vulnerabilities-Liste bestätigt aktive Ausnutzung in realen Angriffen, laut Threat-Intelligence-Teams unter Beteiligung mehrerer APT-Gruppen. Für Security-Teams in DACH ist das eine konkrete Nachricht mit operativen Folgen: ActiveMQ ist in der Mitte vieler Integrationsszenarien im Einsatz, von Legacy-Messaging bis zu modernen Event-Bus-Architekturen. Wer eine exponierte Instanz betreibt und das Update noch nicht eingespielt hat, hat seit dem Wochenende ein offenes Fenster.

VerwandtWindows Defender: BlueHammer und RedSun aktiv ausgenutzt  /  Ransomware-Playbook 72 Stunden

Was CVE-2026-34197 technisch bedeutet und warum ActiveMQ davon betroffen ist

Was ist CVE-2026-34197? CVE-2026-34197 ist eine Sicherheitslücke in Apache ActiveMQ, klassifiziert als Improper Input Validation. Durch speziell präparierte Protokoll-Frames oder HTTP-Requests lassen sich die Eingabeprüfungen im ActiveMQ-Broker umgehen. Im Ergebnis führt das zu nicht autorisierter Ausführung von Code auf dem Server, unter dem Konto, mit dem der Broker läuft. In typischen Setups ist das ein dediziertes Service-Konto mit Dateisystem-Zugriff auf Queues, Logs und Konfiguration. Die Einordnung durch die CISA als bekannt ausgenutzt bedeutet, dass Angreifer die Lücke bereits gegen reale Ziele einsetzen.

ActiveMQ ist als Message Broker in vielen Unternehmen historisch gewachsen. Die Software ist Open Source, wird in Integration-Plattformen, SAP-PI/PO-Ablösungen, Industrie-4.0-Stacks und zunehmend in modernen Event-Bus-Architekturen eingesetzt. Ein wichtiger Punkt für Security-Teams: ActiveMQ hat zwei Produktlinien, die oft durcheinander gehen. Classic ActiveMQ basiert auf dem ursprünglichen Code-Zweig. ActiveMQ Artemis ist aus dem HornetQ-Projekt hervorgegangen. Die betroffenen Module und Patch-Pfade unterscheiden sich, Teams mit Mischbetrieb müssen für beide Linien separat prüfen.

Der zweite häufig übersehene Punkt sind OEM-eingebettete Versionen. Viele Kommerziell-Softwares verwenden ActiveMQ intern, ohne dass das in der Produkt-Dokumentation im Vordergrund steht. Management-Plattformen für Industrie-Anlagen, ERP-Erweiterungen und Middleware-Produkte haben ActiveMQ teilweise als interne Komponente mitgeliefert. Wer eine reine Host-Scan-Inventur macht, übersieht diese Instanzen leicht. Eine vollständige Bestandsaufnahme erfordert deshalb zusätzlich Software-Inventar-Daten und ein Gespräch mit den Hersteller-Supports.

Die Angriffsvoraussetzungen für CVE-2026-34197 sind nach bisherigen Berichten niedrig. Der Broker muss über einen der gängigen Ports erreichbar sein, typischerweise 61616 für OpenWire, 1883 für MQTT oder 5672 für AMQP. Bei den Shadowserver-Scans wurde die Verwundbarkeit primär auf der OpenWire-Schnittstelle festgestellt. Für Angreifer ist das eine komfortable Ausgangslage, weil diese Ports in vielen Firewall-Regeln als technische Infrastruktur freigegeben sind und in Segmentierungs-Konzepten oft nicht als kritisch klassifiziert werden.

Was die 6.364 Instanzen als Signalwert wirklich bedeuten

Der internetweite Scan vom 19.04.2026 hat 6.364 öffentlich erreichbare, als verwundbar bestätigte Instanzen identifiziert. Diese Zahl ist wichtig, aber sie ist nicht die interessanteste. Interessanter ist, was sie verschweigt. Interne Deployments hinter NAT tauchen nicht auf. Netze, die von Shadowserver nicht gescannt werden, ebenfalls nicht. Instanzen in geschlossenen industriellen Netzen fallen durch den Rost. Security-Teams in DACH sollten aus der Zahl nicht ableiten, dass ihr eigenes Risiko klein ist, nur weil ihre Broker nicht im öffentlichen Internet hängen.

Die regionale Verteilung wurde in der Erstveröffentlichung nicht im Detail aufgeschlüsselt, in vergleichbaren Shadowserver-Scans liegt der DACH-Anteil typischerweise zwischen 4 und 8 Prozent der globalen Summe. Hochgerechnet würde das für Deutschland, Österreich und die Schweiz zusammen zwischen 250 und 500 öffentlich exponierte Instanzen bedeuten. Die Dunkelziffer interner Deployments liegt erfahrungsgemäß bei einem Faktor 5 bis 10 über den öffentlichen Zahlen, weil viele Teams ActiveMQ bewusst intern halten.

APT-Aktivität gegen Message Broker hat in den vergangenen Jahren zugenommen. Die Angreifer nutzen kompromittierte Broker als Persistenz-Punkt in Enterprise-Netzwerken, weil Broker oft weitreichende Netzwerk-Verbindungen zu Anwendungen, Datenbanken und Integration-Services unterhalten. Wer einen Broker kontrolliert, hat damit einen privilegierten Sprungpunkt in viele andere Systeme. Die Tatsache, dass CVE-2026-34197 laut Cyberpress.org mit APT-Kampagnen in Verbindung gebracht wird, deutet darauf hin, dass die Verwundbarkeit bereits im Vorfeld von gezielten Gruppen ausgenutzt wurde, bevor sie öffentlich wurde.

„Message Broker sind in vielen Security-Reviews der letzte Stack, den sich jemand genau anschaut. Das ist historisch verständlich, weil Broker als Infrastruktur-Hintergrund wahrgenommen werden. Angreifer wissen das seit Jahren und planen entsprechend.“ Benedikt Langer, Chefredaktion Security Today

Interessant ist der zeitliche Kontext. Die Lücke wurde im April 2026 bekannt, der Scan vom 19.04. dokumentiert die öffentliche Exposure drei Tage nach Verfügbarkeit des Patches. Das Tempo, in dem Angreifer solche Lücken aufgreifen, ist in den letzten zwölf Monaten kürzer geworden. Bei vergleichbaren Vorfällen lag der Abstand zwischen Patch-Release und beobachteter Exploit-Welle bei 48 bis 96 Stunden. Für Security-Teams heißt das: Das Patch-Fenster, in dem man mit Standard-Prozessen reagieren konnte, ist geschrumpft. Notfall-Patch-Prozesse mit 24-Stunden-SLA werden zur Mindest-Erwartung an reife Security-Organisationen.

Was DACH-Security-Teams in dieser Woche konkret tun

Der erste Schritt ist eine vollständige Bestandsaufnahme. Asset-Management-Systeme liefern meist eine erste Liste, aber sie ist selten vollständig. Ergänzend lohnt sich eine gezielte Abfrage gegen Software-Inventories, ERP-Modul-Konfigurationen und Middleware-Stacks. In der Praxis arbeiten sich die meisten Teams in drei Wellen durch: Erste Welle öffentlich exponierte Broker, zweite Welle Broker mit Verbindung zu sensitiven Daten, dritte Welle embedded und OEM-Instanzen. Die dritte Welle ist die zeitaufwändigste, kann aber nicht übersprungen werden.

Der zweite Schritt ist die Entscheidung über Patching versus Abschotten. Wo ein sofortiges Update möglich ist, ist Patchen die einzig saubere Lösung. Wo der Patch-Weg aus Kompatibilitäts- oder Release-Gründen nicht in 48 Stunden durchsetzbar ist, bleibt als Übergangslösung die Port-Filterung. Das bedeutet konkret, den OpenWire-Port 61616 und die anderen Broker-Ports aus Netzen zu entfernen, die für die Broker-Aufgabe nicht zwingend erforderlich sind. Das ist keine Dauerlösung, aber es reduziert das Zeitfenster, in dem ein Angreifer aus dem Internet oder aus kompromittierten Nachbarnetzen angreifen kann.

Der dritte Schritt ist Threat-Hunting. Broker-Logs, Netzwerk-Flow-Daten und Prozess-Historie auf den Broker-Hosts sind die relevanten Datenquellen. Security-Teams, die über ein SIEM mit Broker-Integration verfügen, können gezielt nach Anomalien in den OpenWire- und MQTT-Frames suchen. Wer diese Integration nicht hat, kann alternativ Prozess-Bäume auf den Broker-Hosts nachvollziehen und auf verdächtige Kind-Prozesse prüfen. Shell-Start aus einem ActiveMQ-Service-Konto ist in regulären Setups extrem selten und ein belastbarer Indikator für Kompromittierung.

Der vierte Schritt ist die Kommunikation mit Versicherern und Aufsichtsbehörden. Cyber-Versicherungen erwarten in der aktuellen Vertragsgeneration Dokumentation der Reaktion auf öffentlich bekannt gewordene kritische Lücken. Wer die CVE nicht bearbeitet hat und anschließend einen Vorfall meldet, hat in der Schadensregulierung eine deutlich schwächere Position. Für regulierte Branchen im Scope von NIS2 oder DORA besteht zusätzlich die Pflicht, die Reaktion auf kritische Lücken nachweisbar zu dokumentieren. Ein schriftlicher Vermerk über die Bestandsaufnahme, Patch-Entscheidung und Monitoring-Maßnahmen gehört in die Security-Akte.

Der fünfte Schritt betrifft die strukturelle Konsequenz. Eine einzelne Lücke wie CVE-2026-34197 ist kein Architektur-Problem, sondern ein Patch-Problem. Aber die Wiederkehr dieser Art von Vorfall zeigt, dass Message Broker in vielen Organisationen in einem Graubereich zwischen Infrastruktur und Anwendung liegen, mit unklaren Verantwortlichkeiten für Patches, Monitoring und Härtung. Security-Teams, die nach dem ActiveMQ-Vorfall ihre Broker-Governance neu sortieren, nutzen den Moment. Das bedeutet nicht, Brokers ganz zu ersetzen, sondern klare Owner, definierte Patch-SLAs und integrierte Log-Sichtung festzulegen. Die nächste vergleichbare Lücke kommt mit Sicherheit. Sie trifft Teams mit dieser Grund-Hygiene deutlich weniger hart.

Eine spezifische Nebenbaustelle sind Multi-Tenant-Umgebungen, in denen ein zentraler Broker für mehrere Anwendungen oder Mandanten betrieben wird. Kompromittierung des Brokers betrifft dort nicht nur eine Anwendung, sondern alle angeschlossenen Tenants gleichzeitig. Für Service-Provider und interne Plattform-Teams heißt das, dass die Incident-Kommunikation an Kunden und Fachbereiche eingeplant werden muss, lange bevor ein konkreter Vorfall eintritt. Ein vorbereitetes Benachrichtigungs-Template, klare Eskalations-Stufen und eine vereinbarte Transparenz-Ebene sparen im Ernstfall Stunden, die man sonst mit Rückfragen und Unklarheiten verliert.

Gerade weil Message Broker historisch wenig Aufmerksamkeit bekommen, lohnt sich zudem ein Blick auf die eigene Schulungs-Landschaft. Security-Analysten, die OpenWire-Frames oder AMQP-Protokoll-Eigenschaften nicht kennen, tun sich bei Threat-Hunting schwer. Ein kurzer Workshop mit dem Broker-Team reduziert blinde Flecken in beiden Richtungen und schafft ein gemeinsames Vokabular, das in den kommenden Monaten in Incident-Calls und Post-Mortems gebraucht wird. Die zwei Stunden Investition zahlen sich im ersten ernsthaften Vorfall zigfach zurück. Wer diesen Moment jetzt nicht nutzt, verliert ihn bis zum nächsten vergleichbaren Ereignis. Bis dahin ist der Druck meist höher und die Zeit kürzer als heute.

Häufige Fragen

Welche ActiveMQ-Versionen sind konkret betroffen?

Die Apache Software Foundation hat die betroffenen Versionen in ihrer Sicherheits-Mitteilung zu CVE-2026-34197 aufgelistet. Betroffen sind die jüngsten Classic-ActiveMQ-Releases der 5.x-Linie sowie bestimmte Artemis-Versionen. Teams sollten die Apache-Advisory als primäre Quelle nutzen, weil einzelne Distributionen und Support-Pakete abweichende Versions-Labels tragen können.

Wie schnell sollte der Patch eingespielt werden?

Die CISA-Aufnahme in die KEV-Liste ist der wichtigste Hinweis. Für Bundesbehörden in den USA gilt eine 21-Tage-Frist, für den privaten Sektor hat sich ein 72-Stunden-Ziel als Referenzwert etabliert. Wer wegen Release-Zyklen nicht in 72 Stunden patchen kann, sollte Port-Filterung und verschärftes Monitoring als Übergangsmaßnahmen einsetzen.

Welche Indicators of Compromise gibt es?

Öffentliche Threat-Intelligence-Feeds listen zunehmend konkrete Beobachtungen, darunter ungewöhnliche Kind-Prozesse des ActiveMQ-Service-Kontos, atypische ausgehende Verbindungen zu unbekannten IPv4-Bereichen und Anomalien in der OpenWire-Frame-Größe. Security-Teams sollten diese Feeds in ihr SIEM integrieren und Alerts auf die genannten Muster aktivieren.

Betrifft die Lücke auch Cloud-Services, die ActiveMQ-kompatibel sind?

Cloud-Dienste, die Drop-in-Kompatibilität zu ActiveMQ anbieten, nutzen teilweise eigenständige Implementierungen, teilweise adaptierte Upstream-Codebases. Ob der konkrete Service betroffen ist, muss beim jeweiligen Anbieter erfragt werden. Für Amazon MQ hat AWS typischerweise innerhalb von Stunden bis wenigen Tagen eine offizielle Stellungnahme, Azure Service Bus verwendet keinen ActiveMQ-Codebase und ist nicht betroffen.

Wie wirkt sich ein Vorfall auf NIS2-Meldepflichten aus?

Wer von CVE-2026-34197 betroffen ist und im NIS2-Scope arbeitet, muss bei einem konkreten Sicherheitsvorfall die gestaffelten Meldefristen beachten. 24 Stunden für eine Erstmeldung an das BSI, 72 Stunden für eine qualifizierte Meldung, 30 Tage für einen Abschlussbericht. Ein bloßer Patch-Vorgang ohne konkreten Vorfall löst keine Meldepflicht aus, ein dokumentierter Ausnutzungs-Versuch hingegen schon.

Mehr aus dem MBF Media Netzwerk

Quelle Titelbild: Pexels / panumas nikhomkhai (px:17489150)

Hier schreibt Benedikt Langer für Sie

Mehr Artikel vom Autor Benedikt Langer