Veröffentlicht am 05.08.2026
Am 4. August 2026 hat die US-Cybersicherheitsbehörde CISA die Schwachstelle CVE-2026-34486 in Apache Tomcat in ihren Katalog der aktiv ausgenutzten Sicherheitslücken (Known Exploited Vulnerabilities, kurz KEV) aufgenommen. Das bedeutet im Klartext: Diese Lücke wird nicht nur theoretisch diskutiert – sie wird in der Praxis von Angreifern missbraucht. Bereits Ende April 2026 setzten staatlich unterstützte Angreifer (China-Nexus, Gruppe UNC5174/UNC6586) einen fertigen Exploit gegen taiwanesische Regierungsserver ein.
Das Besondere und zugleich Tückische an dieser Schwachstelle: Sie entstand ausgerechnet durch die Korrektur einer anderen Lücke. Wer im Frühjahr 2026 sein Tomcat aktualisiert hat, um sich abzusichern, kann sich damit ungewollt ein neues Problem eingehandelt haben. In diesem Artikel erklären wir verständlich, was genau passiert ist, wer wirklich betroffen ist – und was Sie jetzt konkret tun müssen.
Apache Tomcat ist ein weit verbreiteter Java-Anwendungsserver – also eine Software, auf der Java-basierte Webanwendungen laufen. Laut Oligo Security nutzen weltweit rund 70 Prozent aller Java-Entwickler Apache Tomcat, und laut 6sense.com setzen über 21.826 Unternehmen die Software ein. Tomcat ist damit ein zentrales Rückgrat vieler Unternehmensanwendungen.
Die Schwachstelle CVE-2026-34486 wurde am 9. April 2026 öffentlich bekannt gemacht und mit einem CVSS-Score von 7.5 (hoch) bewertet. Betroffen sind ausschließlich die folgenden drei Tomcat-Versionen:
Das sind genau jene Versionen, die Apache im März 2026 veröffentlicht hatte, um eine vorherige Lücke – CVE-2026-29146, einen sogenannten Padding-Oracle-Angriff – zu schließen. Bei dieser Korrektur schlich sich jedoch ein Fehler ein, der die neue Lücke CVE-2026-34486 erst schuf. Fachleute nennen so etwas eine Patch-Regression: Ein Bugfix bringt versehentlich ein neues Problem mit sich.
„CVE-2026-34486 ist die schwierigere Lücke. Der Fix für CVE-2026-29146 führte einen Fehler ein, der den EncryptInterceptor umgehbar machte. Teams, die speziell wegen des EncryptInterceptor-Fixes auf 9.0.116 aktualisiert haben, sind schlechter dran als Teams, die das Update übersprungen haben.“ – Mark Szymanski, HeroDevs
Apache Tomcat bietet die Möglichkeit, mehrere Server zu einem Cluster zusammenzuschließen – also einem Verbund, in dem sich die Server gegenseitig Informationen wie Nutzer-Sitzungen (Sessions) austauschen. Für diese interne Kommunikation gibt es den sogenannten EncryptInterceptor, ein Bauteil, das den Datenverkehr zwischen den Servern verschlüsseln soll.
Und genau hier liegt der Fehler. Der Kern des Problems ist – wie es der Sicherheitsanalyst von penligent.ai treffend formuliert – nicht eine obskure Schwäche im Verschlüsselungsalgorithmus, sondern die Position einer einzigen Zeile Programmcode:
„Eine Sicherheitskontrolle muss definieren, was nach einem Fehler passiert. In den verwundbaren Versionen erkannte der Interceptor, dass die Entschlüsselung fehlschlug, und erzeugte einen Fehler – aber die Nachrichtenverarbeitung lief einfach weiter.“ – penligent.ai
Konkret: Der Programmaufruf, der eine empfangene Nachricht weiterverarbeitet (super.messageReceived(msg)), lag außerhalb des Schutzbereichs für die Entschlüsselung. Die Folge war ein sogenanntes Fail-Open-Verhalten: Selbst wenn eine Nachricht nicht korrekt entschlüsselt werden konnte, wurde sie trotzdem weiterverarbeitet – statt sie zu verwerfen. Sicher wäre das umgekehrte Prinzip, Fail-Closed: Im Zweifel ablehnen.
Angreifer können dadurch rohe, unverschlüsselte oder manipulierte Datenpakete an den sogenannten Tribes-Empfänger senden – standardmäßig auf TCP-Port 4000. In Kombination mit anfälligen Java-Bibliotheken (etwa Commons Collections) und einer Technik namens Java-Deserialisierung lässt sich das im schlimmsten Fall bis zur unauthentifizierten Remote Code Execution (RCE) ausbauen – das heißt, ein Angreifer kann ohne Anmeldung beliebige Befehle auf dem Server ausführen, teils sogar mit Root-Rechten.
Der CVSS-Vektor AV:N/AC:L/PR:N/UI:N bedeutet in Alltagssprache: Der Angriff funktioniert über das Netzwerk, ist technisch einfach, erfordert keine Anmeldedaten und kein Zutun des Opfers.
Die gute Nachricht für viele Website-Betreiber vorweg: Nicht jede Tomcat-Installation ist gefährdet. Für eine tatsächliche Ausnutzung müssen mehrere Bedingungen gleichzeitig erfüllt sein:
Für typische KMU-Websites – etwa eine WordPress-Seite oder ein einfacher Firmenauftritt – ist dieses Szenario in der Regel nicht gegeben. Relevant wird es dagegen bei Java-basierten Unternehmensanwendungen: Shop-Systeme (etwa auf Basis von ATG/hybris), ERP-Webportale, Intranet-Anwendungen oder Bildungsplattformen. Hier kann Clustering durchaus im Einsatz sein.
Dass Tomcat tief in Enterprise-Umgebungen verankert ist, zeigt auch die Tatsache, dass Red Hat zwischen April und August 2026 mindestens 13 Sicherheits-Advisories zu dieser einen CVE veröffentlichte.
Arbeiten Sie diese Schritte am besten gemeinsam mit Ihrem IT-Dienstleister oder Administrator ab:
$CATALINA_HOME/bin/version.sh (Linux) bzw. %CATALINA_HOME%\bin\version.bat (Windows) aus. Bei Docker: docker exec <container> sh -c "$CATALINA_HOME/bin/version.sh". Betroffen sind ausschließlich die Versionen 9.0.116, 10.1.53 oder 11.0.20.server.xml nach einem <Cluster>-Element: grep -i "Cluster" $CATALINA_BASE/conf/server.xml. Ist kein solches Element vorhanden, sind Sie nicht betroffen.grep -Rni --include="*.xml" "EncryptInterceptor" $CATALINA_BASE/conf/ $CATALINA_HOME/conf/. Kein Treffer bedeutet: kein Risiko durch diese Lücke.ss -tlnp | grep 4000 oder netstat -tlnp | grep 4000 sehen Sie, ob der Port erreichbar ist. Ist er nur intern gebunden, sinkt das Risiko deutlich.mvn dependency:tree -Dincludes=org.apache.tomcat:tomcat,org.apache.tomcat:tomcat-tribes. Auch Container-Images und Vendor-Distributionen sollten Sie auf Backports prüfen.grep -r "Failed to decrypt message" $CATALINA_HOME/logs/. Wiederholte Einträge mit IllegalBlockSizeException können auf Angriffsversuche hindeuten – dies ist das einzige verräterische Log-Artefakt eines Angriffs.Wenn Sie eine der betroffenen Versionen mit aktivem Clustering und EncryptInterceptor einsetzen, besteht ein hohes, unmittelbares Risiko. Handeln Sie in dieser Reihenfolge:
<Cluster>-Element in server.xml. Das beseitigt den Angriffsweg vollständig.encryptionAlgorithm="AES/GCM/NoPadding" statt des anfälligeren CBC-Modus.Diese Lücke ist keine reine Theorie. Öffentlicher Exploit-Code ist seit dem 15. April 2026 auf GitHub verfügbar und wurde innerhalb weniger Wochen für reale Angriffe genutzt. Die SNOWLIGHT-Kampagne (analysiert von SOCRadar) scannte über 9.990 Hostnamen in 104 Ländern:
„CVE-2026-34486 (Java-Deserialisierung, CommonsCollections6-Gadget) wurde gegen taiwan-fokussierte Ziele ausgenutzt und lieferte bestätigte SNOWLIGHT-Proben. Die Kampagne setzt auf automatisiertes Scannen. Etwa 1 von 90 gescannten Zielen führte zu einem erfolgreichen RCE-Treffer, Diebstahl von Zugangsdaten oder einer Shell-Validierung.“ – SOCRadar Threat Research Unit
Auch das Field Effect Security Intelligence Team warnt, dass öffentlicher PoC-Code die praktische Ausnutzung demonstriert und das Risiko dort erhöht, wo Clustering aktiviert und im Netzwerk exponiert ist. Der EPSS-Score liegt bei 15 Prozent – ein Wert, der eine moderate bis erhöhte Ausnutzungswahrscheinlichkeit innerhalb der nächsten 30 Tage signalisiert. Die CISA gab US-Bundesbehörden eine Frist von nur drei Tagen (bis 7. August 2026) zur Behebung.
Für deutsche Unternehmen hat diese Schwachstelle direkte datenschutzrechtliche Konsequenzen. Werden bei einem Angriff Session-Daten wie Authentifizierungstoken oder Kundendaten offengelegt, liegt eine Verletzung des Schutzes personenbezogener Daten nach Art. 4 Nr. 12 DSGVO vor.
Dass dies kein leeres Drohszenario ist, zeigt ein Präzedenzfall: Die niedersächsische Datenschutzbehörde verhängte ein Bußgeld von 65.500 Euro gegen einen Online-Shop, der trotz Herstellerwarnung veraltete Software mit bekannten Lücken betrieb. Der Bußgeldrahmen für Verstöße gegen Art. 32 und 33 DSGVO reicht bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes. Hinzu kommen mögliche Schadensersatzansprüche Betroffener nach Art. 82 DSGVO. Zur Einordnung: Europaweit wurden 2025 über 167.000 Datenpannen gemeldet – ein Anstieg von 14 Prozent gegenüber dem Vorjahr.
Praxistipp: Dokumentieren Sie Ihre Prüfung und das Update dieser Lücke – auch wenn Sie am Ende nicht betroffen sind. So weisen Sie Ihre Sorgfaltspflicht nach Art. 32 DSGVO nach.
CVE-2026-34486 ist ein Lehrstück darüber, wie ein gut gemeinter Sicherheits-Patch selbst zur Lücke werden kann. Die praktische Gefahr betrifft eine überschaubare, aber wichtige Gruppe: Unternehmen mit Java-basierten Anwendungen, die Tomcat-Clustering mit EncryptInterceptor betreiben und dabei exakt die Versionen 9.0.116, 10.1.53 oder 11.0.20 einsetzen.
Für alle anderen Tomcat-Nutzer ist das Risiko durch diese spezielle Lücke gering – ein Update auf die aktuellen Versionen bleibt aber grundsätzlich Best Practice. Prüfen Sie heute, welche Tomcat-Version bei Ihnen läuft, und ob Clustering aktiv ist. Falls ja: Patchen Sie umgehend auf 9.0.117, 10.1.54 oder 11.0.21. Der Aufwand ist gering – der potenzielle Schaden durch aktive Ausnutzung und mögliche DSGVO-Bußgelder ist es nicht.
Und noch ein Ausblick: Apache Tomcat 9.x erreicht am 31. März 2027 das End-of-Life. Wer noch auf der 9er-Reihe läuft, sollte jetzt die Migration auf Tomcat 10.1 oder 11.0 planen.