Veröffentlicht am 06.08.2026
Chinesische Angreifer nutzen derzeit eine Schwachstelle in Apache Tomcat aus, um sich vollständige Kontrolle über verwundbare Server zu verschaffen – und sie tun das mit einer beunruhigenden neuen Methode: Ihre Angriffe werden von künstlicher Intelligenz automatisiert und skaliert. Am 4. August 2026 nahm die US-Cybersicherheitsbehörde CISA die Sicherheitslücke CVE-2026-34486 in ihren Katalog der aktiv ausgenutzten Schwachstellen (Known Exploited Vulnerabilities, kurz KEV) auf. Wenn Sie einen Apache-Tomcat-Server betreiben, sollten Sie jetzt handeln.
Apache Tomcat ist eine weit verbreitete Software, die Java-basierte Webanwendungen ausführt – man kann sie sich als Motor vorstellen, der im Hintergrund viele Unternehmenswebsites und Web-Applikationen antreibt. Genau in diesem Motor steckt die Lücke.
Die Schwachstelle CVE-2026-34486 (Schweregrad CVSS 7.5, „High") ist besonders ärgerlich, weil sie eine sogenannte Regression ist: Sie entstand durch einen fehlerhaften Patch für eine frühere Lücke namens CVE-2026-29146. Mit anderen Worten: Der Versuch, ein altes Problem zu beheben, hat ein neues geschaffen. Die Apache Software Foundation formuliert es so:
„An error in the fix for CVE-2026-29146 allowed the EncryptInterceptor to be bypassed." – Apache Software Foundation
Übersetzt heißt das: Ein Fehler in der Behebung der vorherigen Lücke erlaubt es Angreifern, den sogenannten EncryptInterceptor zu umgehen. Der EncryptInterceptor ist eine Schutzfunktion, die die Kommunikation zwischen mehreren zusammengeschalteten Tomcat-Servern (einem „Cluster") verschlüsselt. Wird dieser Schutz umgangen, können sensible Daten unverschlüsselt übertragen und abgefangen werden. Technisch wird die Lücke als „Missing Encryption of Sensitive Data" (fehlende Verschlüsselung sensibler Daten) klassifiziert.
Das Alarmierende: Die Lücke wird bereits aktiv ausgenutzt. Der Sicherheitsdienstleister Palo Alto Networks Unit 42 berichtete am 30. Juli 2026 über eine Angriffskampagne, bei der ein chinesischsprachiger Bedrohungsakteur (bekannt unter den Aliassen knaithe beziehungsweise KnYuan) diese und weitere Schwachstellen ausnutzte. Dabei platzierten die Angreifer sogenannte Reverse Shells auf neun Apache-Tomcat-Servern. Eine Reverse Shell ist eine versteckte Verbindung, die dem Angreifer aus der Ferne die volle Kontrolle über das System gibt – als säße er direkt an der Tastatur.
Was die Angreifer besonders gefährlich macht, ist ihre Vorgehensweise. Laut Unit 42 handelt es sich um eine KI-gestützte, autonome Angriffskampagne:
„Unit 42 identified an AI-enabled autonomous hacking campaign carried out by a Chinese-speaking threat actor. They targeted infrastructure using seven vulnerabilities, combining autonomous AI-driven enumeration with manual exploitation that achieved confirmed impact." – Palo Alto Networks Unit 42
Die Angreifer setzen ein KI-Modell (DeepSeek, gesteuert über einen sogenannten „Hermes Agent") ein, um automatisiert nach verwundbaren Systemen zu suchen und diese zu attackieren. Das bedeutet: Angriffe, für die früher menschliche Hacker viel Zeit brauchten, laufen jetzt teilautomatisiert und in großem Umfang ab.
Für den eigentlichen Einbruch nutzen die Angreifer eine Technik namens Java-Deserialisierung – konkret über ein sogenanntes CommonsCollections6-Gadget mit dem bekannten Werkzeug „ysoserial". Vereinfacht gesagt schleusen sie manipulierte Daten ein, die der Server dann als Programmcode ausführt. So erreichen sie eine Remote Code Execution (RCE) – die Ausführung beliebigen Schadcodes aus der Ferne, die schwerste Kategorie einer Kompromittierung.
Als Schadsoftware kommt dabei die Malware-Familie SNOWLIGHT zum Einsatz. Der Sicherheitsdienstleister SOCRadar ordnet diese klar staatsnahen chinesischen Akteuren zu:
„The core delivery mechanisms have been definitively linked to the SNOWLIGHT malware family. Tracked by the Google Threat Intelligence Group since 2024, identified loaders are heavily associated with China-nexus access brokers UNC5174 and UNC6586." – SOCRadar Threat Research Unit
Wichtig zu verstehen: Die Patches sind bereits seit April 2026 verfügbar. Wer bis heute nicht aktualisiert hat, ist seit Monaten angreifbar.
Betroffen sind alle Apache-Tomcat-Installationen in Versionen vor 11.0.21, 10.1.54 und 9.0.117. Die Lücke betrifft insbesondere Systeme, die den EncryptInterceptor für Cluster-Kommunikation nutzen.
Auch wenn Apache Tomcat häufig als interne Middleware – also als Zwischenschicht ohne direkten Internetkontakt – eingesetzt wird, ist die Angriffsfläche riesig: Laut Scans waren im Oktober 2025 weltweit über 540.000 Apache-Tomcat-Instanzen öffentlich aus dem Internet erreichbar. Tomcat hat einen erheblichen Marktanteil bei Web- und Applikationsservern, rund 42 Prozent der Kunden stammen aus den USA – aber auch in Deutschland ist die Software weit verbreitet.
Für kleine und mittlere Unternehmen ist das Risiko sehr hoch. Wenn Ihre Website, Ihr Kundenportal oder eine interne Anwendung auf Java-Basis läuft, stehen die Chancen gut, dass irgendwo im Hintergrund ein Tomcat-Server arbeitet – oft von einem Dienstleister aufgesetzt und dann in Vergessenheit geraten.
Sollten Sie Hinweise auf Punkt 3 oder 4 finden, gehen Sie von einer Kompromittierung aus und ziehen Sie umgehend einen IT-Sicherheitsexperten hinzu – und beachten Sie die weiter unten genannten DSGVO-Meldepflichten.
Wenn Ihre Website oder Anwendung von einem externen Dienstleister oder Hosting-Anbieter betreut wird, fragen Sie noch heute nach, welche Tomcat-Version im Einsatz ist und ob der Patch bereits eingespielt wurde. Lassen Sie sich das schriftlich bestätigen.
Diese Schwachstelle ist aus zwei Gründen besonders ernst zu nehmen. Erstens wird sie nicht von Gelegenheitshackern ausgenutzt, sondern von hochprofessionellen, staatsnahen chinesischen Akteuren. Zweitens skalieren diese ihre Angriffe mit künstlicher Intelligenz – das bedeutet, dass auch kleinere, weniger prominente Ziele automatisiert gefunden und attackiert werden. Die Vorstellung, „für Angreifer zu unwichtig" zu sein, greift bei automatisierten Massenscans nicht mehr.
Ein erfolgreicher Angriff führt zur vollständigen Kompromittierung des Servers. Damit erlangen die Angreifer potenziell Zugriff auf alle Daten, die auf diesem System verarbeitet werden – einschließlich personenbezogener Daten Ihrer Kunden.
Genau hier kommt die Datenschutz-Grundverordnung (DSGVO) ins Spiel. Da die Lücke auf einer fehlenden Verschlüsselung sensibler Daten beruht und Angreifer volle Kontrolle über den Server erlangen können, besteht ein sehr hohes Risiko eines Datenabflusses. Nach Artikel 33 DSGVO müssen Sie eine Verletzung des Schutzes personenbezogener Daten unverzüglich und möglichst innerhalb von 72 Stunden an die zuständige Aufsichtsbehörde melden – es sei denn, die Verletzung führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten betroffener Personen.
Bei einer Kompromittierung durch Reverse Shell und RCE ist dieses „geringe Risiko" praktisch nicht mehr gegeben – eine Meldung ist in der Regel zwingend erforderlich. Zusätzlich kann nach Artikel 34 DSGVO eine Informationspflicht gegenüber den betroffenen Personen selbst bestehen. Wer bei alldem nachweisbar unzureichende Schutzmaßnahmen getroffen hat – etwa monatelang verfügbare Patches nicht einspielt –, riskiert Bußgelder nach Artikel 83 DSGVO.
CVE-2026-34486 ist ein Lehrstück dafür, warum das zügige Einspielen von Sicherheitsupdates keine Fleißaufgabe, sondern eine Pflicht ist. Die Patches stehen seit April 2026 bereit – trotzdem gelang es Angreifern über Monate, verwundbare Server zu kapern. Mit der Aufnahme in den CISA-KEV-Katalog am 4. August 2026 ist offiziell bestätigt: Diese Lücke wird aktiv ausgenutzt, und zwar von hochprofessionellen, KI-gestützten Akteuren.
Für kleine und mittlere Unternehmen bedeutet das konkret: Prüfen Sie noch heute, ob und in welcher Version Apache Tomcat bei Ihnen im Einsatz ist, und aktualisieren Sie umgehend auf 11.0.21, 10.1.54 oder 9.0.117. Schotten Sie Ihre Server vom offenen Internet ab und untersuchen Sie Ihre Logs auf die genannten Kompromittierungs-Indikatoren. Und falls Sie einen Dienstleister mit dem Betrieb betraut haben: Fordern Sie eine schriftliche Bestätigung ein, dass der Patch eingespielt wurde.
Die Kombination aus verfügbarem Patch, aktiver Ausnutzung und hohem DSGVO-Risiko lässt keinen Spielraum für Aufschub. Handeln Sie jetzt – bevor die Automatisierung der Angreifer Ihren Server findet.