Apache Tomcat: Aktiv ausgenutzte Verschlüsselungs-Lücke (CVE-2026-34486)

Veröffentlicht am 10.08.2026

Eine Verschlüsselung, die eigentlich schützen soll, lässt Angreifer ungehindert durch – und das seit einem Patch, der genau diese Verschlüsselung reparieren sollte. Genau das ist beim weltweit verbreiteten Java-Webserver Apache Tomcat passiert. Die Sicherheitslücke CVE-2026-34486 ermöglicht es Angreifern, ohne Zugangsdaten Schadcode auf verwundbaren Servern auszuführen und die vollständige Kontrolle zu übernehmen. Am 4. August 2026 hat die US-Cybersicherheitsbehörde CISA die Schwachstelle in ihren Katalog der aktiv ausgenutzten Sicherheitslücken (KEV, „Known Exploited Vulnerabilities“) aufgenommen – ein deutliches Signal, dass die Lücke bereits in freier Wildbahn missbraucht wird.

Für kleine und mittlere Unternehmen, die Tomcat betreiben – oft ohne es überhaupt zu wissen, weil er in vielen Anwendungen eingebettet steckt – besteht akuter Handlungsbedarf. In diesem Artikel erklären wir, was passiert ist, wer betroffen ist, wie Sie prüfen, ob Ihr System verwundbar ist, und was Sie jetzt konkret tun müssen.

Was ist passiert?

Apache Tomcat ist einer der am häufigsten eingesetzten Java-Webserver und sogenannten Servlet-Container – also die Software, die im Hintergrund läuft, um Java-Web-Anwendungen bereitzustellen. Er steckt in unzähligen Web-Applikationen und CMS-Backends. Laut Schätzungen sind weltweit über 540.000 Tomcat-Instanzen direkt aus dem Internet erreichbar.

Die Lücke CVE-2026-34486 hat einen offiziellen Schweregrad von CVSS 7.5 („High“). Durch die aktive Ausnutzung ist das reale Risiko jedoch deutlich höher einzuschätzen. Das Problem betrifft den sogenannten EncryptInterceptor – eine Komponente, die die Kommunikation zwischen mehreren Tomcat-Servern in einem Verbund (einem „Cluster“) verschlüsseln soll.

Besonders brisant: Die Schwachstelle entstand nicht durch eine ursprüngliche Programmierlücke, sondern durch einen fehlerhaften Patch. Im März 2026 wurde die vorherige Lücke CVE-2026-29146 behoben. Bei dieser Korrektur wurde jedoch unbemerkt ein neuer, schwerwiegender Fehler eingeführt. Sicherheitsforscher sprechen von einer „Fail-Open“-Regression – dazu gleich mehr.

Der technische Hintergrund – verständlich erklärt

Der EncryptInterceptor soll wie ein Türsteher funktionieren: Nur korrekt verschlüsselte Nachrichten dürfen passieren, alles andere wird abgewiesen. Fachleute nennen dieses sichere Verhalten „Fail-Closed“ – im Zweifelsfall bleibt die Tür geschlossen.

Durch den fehlerhaften Patch wurde jedoch eine einzige Codezeile an die falsche Stelle verschoben. Konkret wurde der Befehl super.messageReceived(msg); aus dem sogenannten try-Block (dem Bereich, der nur bei erfolgreicher Verschlüsselung ausgeführt wird) in den catch-Block (den Fehlerbehandlungsbereich) verlagert. Die Folge: Schlägt die Entschlüsselung einer manipulierten Nachricht fehl, wird der Fehler zwar protokolliert – die Nachricht aber trotzdem verarbeitet. Der Türsteher notiert den Regelverstoß, lässt den Angreifer aber trotzdem hinein. Das ist das gefährliche „Fail-Open“-Verhalten.

Der Sicherheitsforscher Bartłomiej Dmitruk vom Unternehmen Striga, das die Regression entdeckte, beschreibt es so:

„Die Verschlüsselungsschicht, der sie vertrauten, ließ stillschweigend jede Nachricht durch, deren Entschlüsselung fehlschlug. […] Eine unauthentifizierte TCP-Verbindung führt zu beliebiger Befehlsausführung – über einen Interceptor, der eigentlich alles verwerfen sollte, was er nicht entschlüsseln konnte.“

Praktisch bedeutet das: Ein Angreifer, der Netzwerkzugriff auf den Cluster-Kommunikationsport (standardmäßig Port 4000) hat, kann sogenannte bösartige serialisierte Java-Objekte einschleusen. Über bekannte „Gadget-Chains“ (fertige Angriffsbausteine, etwa ysoserial CommonsCollections6) lässt sich so beliebiger Code mit den Rechten des Tomcat-Prozesses ausführen. Das Ergebnis ist eine unauthentifizierte Remote Code Execution (RCE) – die Fähigkeit, aus der Ferne und ohne jegliche Zugangsdaten Befehle auf dem Server auszuführen. Das ist der Worst Case für jeden Serverbetreiber.

Wird die Lücke bereits ausgenutzt?

Ja – und zwar aktiv und in großem Stil. Die Ausnutzung wurde bereits einer chinesischen Hackergruppe zugeordnet, die unter den Bezeichnungen UNC5174/UNC6586 geführt wird und im Rahmen der sogenannten SNOWLIGHT-Kampagne agiert. Diese Angreifer gehören zur Kategorie der Advanced Persistent Threats (APT) – hochprofessionelle, oft staatsnahe Angreifergruppen.

Die Zahlen aus der Kampagne verdeutlichen die Dimension:

• Über 9.990 Hostnames in 104 Ländern wurden gescannt.
• Rund 85 Prozent der angegriffenen Ziele gehörten zur nationalen Infrastruktur oder zu Regierungsbehörden.

Die SOCRadar Threat Research Unit beschreibt das Vorgehen als hochgradig automatisiert:

„Die Kampagne zeigt ein höchst opportunistisches und automatisiertes ‚Spray-and-Check‘-Modell, das von China-nahen Bedrohungsakteuren eingesetzt wird, um ein breites Spektrum globaler Regierungs- und Unternehmensinfrastruktur zu kompromittieren.“

Dieses „Spray-and-Check“-Modell bedeutet: Angreifer scannen wahllos das Internet nach verwundbaren Systemen und schlagen automatisiert zu. Kein Unternehmen ist zu klein, um ins Visier zu geraten – gescannt wird alles.

Wer ist betroffen?

Betroffen sind konkret die Tomcat-Versionen 9.0.116, 10.1.53 und 11.0.20. Diese Versionen enthalten den fehlerhaften Patch, der die Lücke erst eingeführt hat.

Wichtig für KMU: Tomcat läuft häufig nicht als sichtbare, eigenständige Software, sondern eingebettet in Spring Boot oder anderen Java-Anwendungen. Viele Unternehmen betreiben CRM-Systeme, Online-Shops oder das Backend ihrer Web-Apps auf Basis von Tomcat, ohne sich dessen bewusst zu sein. Fragen Sie im Zweifel Ihren IT-Dienstleister oder Ihre Softwareentwickler gezielt nach der eingesetzten Tomcat-Version.

Auch das Bundesamt für Sicherheit in der Informationstechnik (BSI) warnt:

„Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Apache Tomcat und Tomcat Native ausnutzen, um Informationen offenzulegen und Sicherheitsmaßnahmen zu umgehen.“

So prüfen Sie, ob Sie betroffen sind

Gehen Sie die folgenden vier Schritte durch, um Ihre Betroffenheit einzuschätzen:

1. Version prüfen: Ermitteln Sie die eingesetzte Apache-Tomcat-Version. Betroffen sind konkret die Versionen 9.0.116, 10.1.53 und 11.0.20.
2. Konfiguration kontrollieren: Prüfen Sie die Datei server.xml oder Ihre Cluster-Konfigurationsdateien auf die Verwendung des EncryptInterceptor. Nur wenn diese Komponente aktiv ist, sind Sie über diesen Weg angreifbar.
3. Port-Erreichbarkeit prüfen: Kontrollieren Sie, ob die Tomcat-Cluster-Ports (meist Port 4000) aus dem Internet oder aus unvertrauten Netzwerken erreichbar sind. Ist dieser Port offen erreichbar, ist das Risiko am höchsten.
4. Logs untersuchen: Durchsuchen Sie die Tomcat-Logs (z. B. catalina.out) nach der Fehlermeldung „Failed to decrypt message“, gefolgt von „javax.crypto.AEADBadTagException“ oder „BadPaddingException“. Ein gehäuftes Auftreten dieser Fehler kann auf laufende Ausnutzungsversuche hindeuten.

Das müssen Sie jetzt tun

Angesichts der aktiven, automatisierten Ausnutzung ist schnelles Handeln entscheidend. Folgen Sie diesen Schritten in dieser Reihenfolge:

1. Umgehend patchen: Installieren Sie sofort das Update auf eine der bereinigten Versionen Tomcat 11.0.21, 10.1.54 oder 9.0.117. Diese Versionen wurden am 4. April 2026 von Apache veröffentlicht und schließen die Lücke.
2. Cluster-Port isolieren: Stellen Sie per Firewall sicher, dass Port 4000 niemals aus dem Internet erreichbar ist, sondern ausschließlich von vertrauenswürdigen Cluster-Knoten – etwa über ein dediziertes VLAN (getrenntes Netzsegment) oder ein VPN. Dieser Schritt reduziert das Risiko drastisch, selbst wenn noch nicht gepatcht wurde.
3. Übergangsmaßnahme, falls Update nicht sofort möglich: Deaktivieren Sie den EncryptInterceptor, sofern die Cluster-Kommunikation ohnehin in einem isolierten, vertrauenswürdigen Netzwerk stattfindet – oder stellen Sie den Verschlüsselungsalgorithmus auf AES/GCM/NoPadding um.
4. Veraltete Versionen ablösen: Ältere, bereits End-of-Life (EOL) befindliche Versionen wie Tomcat 8.5 erhalten keine offiziellen Patches mehr. Hier hilft nur eine kommerzielle Extended-Support-Lösung oder – besser – eine schnellstmögliche Migration auf eine unterstützte Version.

Der zeitliche Ablauf im Überblick

• 22. Februar 2026: Die vorherige Lücke CVE-2026-29146 (ein „Padding Oracle“) wird an Apache gemeldet.
• 13. März 2026: Der Patch für CVE-2026-29146 wird umgesetzt – und führt unbemerkt die neue Bypass-Lücke ein.
• 25. März 2026: Das Sicherheitsunternehmen Striga entdeckt die Regression und meldet CVE-2026-34486 an Apache.
• 4. April 2026: Apache veröffentlicht die bereinigten Versionen 11.0.21, 10.1.54 und 9.0.117.
• 9. April 2026: Öffentliche Bekanntgabe der Lücke über die Apache-Mailingliste und die NVD-Datenbank.
• 24. April 2026: Beginn der aktiven Ausnutzung in der SNOWLIGHT-Kampagne.
• 4. August 2026: CISA nimmt CVE-2026-34486 offiziell in den KEV-Katalog auf.

Warum das auch ein DSGVO-Problem ist

Eine erfolgreiche Ausnutzung dieser Schwachstelle bedeutet die vollständige Übernahme des Servers – und damit Zugriff auf alle dort verarbeiteten Daten. Da Tomcat bei KMU häufig CRM-Systeme, Shops oder Web-App-Backends antreibt, sind dabei in aller Regel personenbezogene Daten betroffen.

Damit greifen zentrale Pflichten der Datenschutz-Grundverordnung:

• Meldepflicht nach Art. 33 DSGVO: Bei einem solchen Vorfall müssen Sie die zuständige Datenschutzaufsichtsbehörde innerhalb von 72 Stunden informieren – es sei denn, ein Risiko für die Rechte und Freiheiten natürlicher Personen lässt sich ausschließen. Bei einer RCE-Kompromittierung ist das kaum möglich.
• Sicherheit der Verarbeitung nach Art. 32 DSGVO: Wer ungepatchte, aus dem Internet erreichbare Systeme betreibt, riskiert einen Verstoß gegen die Pflicht zu angemessenen technischen und organisatorischen Maßnahmen (TOMs).

Die Bußgelder können empfindlich ausfallen: theoretisch bis zu 20 Millionen Euro oder 4 Prozent des weltweiten Jahresumsatzes. In der Praxis bewegen sich Bußgelder für unzureichende TOMs bei KMU typischerweise zwischen 10.000 und 100.000 Euro – ein Schaden, der viele kleine Betriebe empfindlich trifft.

Fazit

CVE-2026-34486 ist ein Lehrstück darüber, wie ein gut gemeinter Sicherheitspatch eine neue, gefährlichere Lücke schaffen kann. Aus einer Verschlüsselung, die schützen sollte, wurde ein offenes Tor. Dass die Lücke ohne Authentifizierung ausnutzbar ist, dass fertige Exploits existieren und dass professionelle Angreifergruppen bereits automatisiert das gesamte Internet nach verwundbaren Systemen absuchen, macht sie zu einer der derzeit dringlichsten Bedrohungen für Tomcat-Betreiber.

Die gute Nachricht: Die Absicherung ist eindeutig und gut machbar. Prüfen Sie Ihre Tomcat-Version, aktualisieren Sie umgehend auf 11.0.21, 10.1.54 oder 9.0.117 und schließen Sie den Cluster-Port 4000 gegenüber dem Internet konsequent per Firewall ab. Sprechen Sie gezielt mit Ihrem IT-Dienstleister – gerade weil Tomcat oft unsichtbar in andere Anwendungen eingebettet ist, wissen viele Unternehmen gar nicht, dass sie betroffen sein könnten. Wer jetzt handelt, verhindert nicht nur eine mögliche Serverübernahme, sondern auch eine potenziell teure DSGVO-Datenpanne.