Was sind Apache-Tomcat-Sicherheitslücken: Erkennung, Behebung und Tipps

Wichtigste Erkenntnisse

• Die meisten Risiken bei Tomcat gehen auf bekannte, nicht gepatchte CVEs in alten oder nicht mehr unterstützten Versionen zurück.
• Schwerwiegende Sicherheitslücken wie CVE-2025-24813 und Ghostcat erfordern bestimmte risikobehaftete Einstellungen, um ausgenutzt werden zu können.
• Die Erkennung beginnt damit, dass Sie wissen, welche Tomcat-Versionen Sie einsetzen und welche risikobehafteten Einstellungen aktiviert sind.
• Führen Sie Upgrades durch, wo es möglich ist, ergreifen Sie in der Konfiguration Abhilfemaßnahmen, wo dies nicht möglich ist, und lassen Sie EOL-Builds niemals ungeschützt.

Ein Team aktiviert den Schreibzugriff auf das Standard-Servlet von Tomcat, um eine Datei-Upload-Funktion zu unterstützen, stellt die Anwendung bereit und widmet sich anderen Aufgaben. Dabei wird übersehen, dass „Partial PUT“ standardmäßig aktiviert ist, sodass nun eine der Voraussetzungen für CVE-2025-24813 vorliegt. Wenn diese Anwendung zudem die dateibasierte Sitzungspermanenz von Tomcat am Standard-Speicherort nutzt und zufällig eine Bibliothek enthält, die zur Deserialisierung missbraucht werden kann, ist das Ergebnis die nicht authentifizierte Remote-Code-Ausführung. Die CISA hat diese Schwachstelle seit dem 1. April 2025 in ihrem Katalog „Known Exploited Vulnerabilities“ aufgeführt.

Das ist das immer wiederkehrende Muster hinter Tomcat-Vorfällen. Selten handelt es sich um einen raffinierten neuen Angriff. Meistens ist es ein bekanntes Problem, das in einer alten Version unberücksichtigt blieb, oder eine riskante Einstellung, die niemand noch einmal überprüft hat.

Dieser Leitfaden gibt einen Überblick über die Risiken, die wichtigsten CVEs sowie darüber, wie Sie Schwachstellen erkennen, beheben und Ihre Server absichern können.

Welche Risiken bergen Sicherheitslücken in Apache Tomcat?

Tomcat ist einer der am häufigsten eingesetzten Java-Servlet-Container, was ihn zu einem ständigen Angriffsziel macht. Wenn eine Sicherheitslücke bekannt wird, beschränkt sich der Schaden selten auf nur einen Server.

Der schlimmste Fall ist die Ausführung von Remote-Code, bei der ein Angreifer beliebige Befehle auf dem Host ausführt. Eine Stufe darunter liegt die Offenlegung von Informationen, bei der Dateien wie „web.xml“, Quellcode oder vertrauliche Konfigurationsdaten ohne Authentifizierung eingesehen werden können. Dann gibt es noch die Inhaltsinjektion, bei der bösartige Daten in hochgeladene Dateien oder Sitzungsdaten eingeschleust werden. Und jede kompromittierte Tomcat-Instanz bietet einen günstigen Ausgangspunkt für laterale Bewegungen in den Rest des Netzwerks.

Realitätscheck: Die Aussage „Wir haben ein Upgrade durchgeführt, also ist alles in Ordnung“ zieht nicht, wenn auf einigen Instanzen ein Zweig mit abgelaufenem Support-Zeitraum läuft. Tomcat 8.5 hat am 31. März 2024 das Ende seines Support-Zeitraums erreicht und erhielt nie einen Upstream-Patch für CVE-2025-24813. Ohne einen Anbieter, der Patches nach Ablauf des Support-Zeitraums bereitstellt, bleiben diese Server angreifbar – ganz gleich, wie viele andere Server Sie gepatcht haben.

Häufige Sicherheitslücken bei Apache Tomcat

Die CVEs für Tomcat konzentrieren sich auf eine Handvoll Themen. Unsichere Anfragebearbeitung, Protokollvertrauen, Pfadauflösung, Authentifizierungslogik und unsichere Standard-Verschlüsselungseinstellungen decken den Großteil davon ab. Hier sind die wichtigsten davon, zusammen mit den betroffenen und behobenen Versionen, die Apache veröffentlicht.

CVE-2025-24813 (Teilweise RCE durch PUT)

In diesem Fall geht ein Fehler bei der Pfadäquivalenz mit einer unsicheren Deserialisierung einher, und die Voraussetzungen sind zwar spezifisch, aber durchaus realistisch. Schreibzugriffe müssen für das Standard-Servlet aktiviert sein, was standardmäßig nicht der Fall ist. Teilweise PUT-Anfragen müssen aktiviert sein, was standardmäßig der Fall ist.

Die Anwendung muss die dateibasierte Sitzungspermanenz von Tomcat am Standard-Speicherort nutzen. Außerdem muss die Anwendung eine Bibliothek enthalten, die für einen Deserialisierungsangriff missbraucht werden kann. Sind alle vier Bedingungen erfüllt, kann ein Angreifer eine serialisierte Nutzlast mit einem partiellen PUT-Befehl vorbereiten und anschließend die Ausführung mit einer Folgeanfrage auslösen, die die passende JSESSIONID enthält.

Am 10. März 2025 wurde dies öffentlich bekannt gegeben, und die CISA nahm es am 1. April 2025 in den Katalog der bekannten ausgenutzten Sicherheitslücken auf.

CVE-2020-1938 (Ghostcat)

Ghostcat ist eine Schwachstelle beim Lesen und Einbinden von Dateien im AJP-Konnektor, der ursprünglich standardmäßig auf Port 8009 aktiviert und an jede konfigurierte Adresse gebunden war. Ein entfernter, nicht authentifizierter Angreifer, der diesen Port erreichen konnte, war in der Lage, beliebige Dateien aus beliebigen Bereichen der Webanwendung – einschließlich der Verzeichnisse „WEB-INF“ und „META-INF“ – abzurufen und Tomcat dazu zu bringen, jede Datei in der Anwendung als JSP zu verarbeiten. Dies führt zur Codeausführung, wenn die Anwendung hochgeladene Dateien zudem innerhalb der Webanwendung speichert. Die Korrekturen wurden in den Versionen 7.0.100, 8.5.51 und 9.0.31 implementiert. In diesen Versionen hat Apache den Konnektor außerdem in der Standarddatei „server.xml“ auskommentiert, seine Standard-Bind-Adresse auf Loopback verschoben und ein AJP-Geheimnis zwingend vorgeschrieben. Die Schwachstelle ist seit dem 3. März 2022 im KEV-Katalog aufgeführt.

CVE-2025-55752 (Verzeichnisüberquerung)

Eine Regression im „Rewrite Valve“ normalisierte umgeschriebene URLs, bevor diese dekodiert wurden. Wenn Umschreibungsregeln Abfrageparameter in die URL verschieben, könnte ein Angreifer die Anfrage-URI manipulieren, um die Schutzmaßnahmen für /WEB-INF/ und /META-INF/ zu umgehen – wobei auch die Ausführung von Code möglich wäre, falls PUT ebenfalls aktiviert wäre. Apache merkt an, dass diese Kombination unwahrscheinlich ist, da PUT normalerweise auf vertrauenswürdige Benutzer beschränkt ist, doch der Fall ist dennoch lesenswert. Er zeigt, wie eine Korrektur in einer Version unbemerkt in einer anderen Version erneut ein Risiko einführen kann.

CVE-2026-29146 (EncryptInterceptor-Padding-Oracle)

Eine gute Erinnerung daran, dass eine Standardeinstellung eine Sicherheitslücke darstellen kann. Der „EncryptInterceptor“, der zur Verschlüsselung des Cluster-Datenverkehrs verwendet wird, war standardmäßig auf den CBC-Modus eingestellt, der für Padding-Oracle-Angriffe anfällig ist. Jede Bereitstellung, bei der dieser Interceptor im Standard-Verschlüsselungsmodus lief, war potenziell gefährdet, ohne dass ein Administrator etwas Ungewöhnliches ausgewählt hatte. Für Versionen, die vom „Endless Lifecycle Support“ von TuxCare abgedeckt sind, werden zurückportierte Korrekturen pro Version im CVE-Tracker nachverfolgt, der genau anzeigt, für welche abgedeckten Releases die Korrektur verfügbar ist.

CVE-2026-34486 (Umgehung von „EncryptInterceptor“)

Der Fix für CVE-2026-29146 wurde in den Versionen 9.0.116, 10.1.53 und 11.0.20 bereitgestellt und wies einen Fehler auf, durch den der EncryptInterceptor vollständig umgangen werden konnte. Beachten Sie dabei die Tomcat-11-Versionsnummer. Der Fix wurde für 11.0.19 geschrieben, doch die Abstimmung über diese Version scheiterte, sodass 11.0.20 der erste Build war, den man tatsächlich herunterladen konnte. Genau diese drei Versionen sind betroffen, und die Probleme werden mit den Versionen 9.0.117, 10.1.54 und 11.0.21 behoben. Die CISA hat diesen Eintrag am 4. August 2026 in den KEV-Katalog aufgenommen; ein Cluster-Upgrade, das bei der ersten Korrektur Halt gemacht hat, ist also noch nicht abgeschlossen.

CVE-2026-55957 (Umgehung der GSSAPI-Authentifizierung)

Wenn JNDIRealm so konfiguriert war, dass Bind-Vorgänge über GSSAPI authentifiziert wurden, konnte sich ein Angreifer ohne das richtige Passwort authentifizieren. Weder Brute-Force-Angriffe noch gestohlene Anmeldedaten waren erforderlich. Die Authentifizierungslogik versäumte es einfach, die Überprüfung durchzusetzen. Seltsam ist der zeitliche Ablauf. Der Fix wurde stillschweigend in den Versionen 9.0.102, 10.1.39 und 11.0.5 ausgeliefert, und das Problem wurde erst am 29. Juni 2026, mehr als ein Jahr später, öffentlich gemacht. Alle Versionen bis einschließlich 9.0.100, 10.1.36 oder 11.0.4 erfordern besondere Aufmerksamkeit. Neuere Versionen waren bereits abgesichert, bevor die CVE-Nummer vergeben wurde.

CVE-2026-43512 (Digest-Authentifizierung mit „null“-Passwort)

Die Art des Fehlers ist hier fast zu einfach, um wahr zu sein. Der Digest-Authentifikator von Tomcat akzeptierte die Zeichenfolge „null“ als gültiges Passwort für jeden Benutzernamen, der im konfigurierten Realm nicht vorhanden war. Somit konnte sich ein Benutzer, der nicht im System vorhanden war, durch Erraten dieser Zeichenfolge authentifizieren. Das Ausmaß der Auswirkungen hängt davon ab, was hinter der Digest-Authentifizierung steht, doch die Voraussetzung dafür ist leicht zu erfüllen. Die Schwachstelle wurde am 12. Mai 2026 veröffentlicht und in den Versionen 9.0.118, 10.1.55 und 11.0.22 behoben.

Wussten Sie schon: Im März 2025 blockierte Palo Alto Networks innerhalb von drei Wochen nach Bekanntgabe 125.856 Scans, Sondierungsversuche und Exploit-Versuche im Zusammenhang mit CVE-2025-24813 und zwei damit verbundenen Sicherheitslücken in Apache Camel, die aus mehr als 70 Ländern stammten.

So erkennen und bewerten Sie Sicherheitslücken in Apache Tomcat

Die Erkennung ist in erster Linie ein Inventarproblem. Was man nicht gefunden hat, kann man auch nicht patchen, und in größeren Umgebungen sammeln sich häufig Tomcat-Instanzen an, die es nie auf eine Liste geschafft haben. Gehen Sie diese drei Schritte der Reihe nach durch.

Alle Instanzen und Versionen erfassen

Ermitteln Sie alle Tomcat-Bereitstellungen, einschließlich Anwendungen, in die Tomcat eingebettet ist, wie beispielsweise Spring-Boot-Anwendungen, auf denen der eingebettete Tomcat-Server läuft. Notieren Sie die genaue Version, nicht den Ordnernamen. Da Installationen kopiert und umbenannt werden, ist der Pfad irreführend.

Profi-Tipp: Führen Sie das mitgelieferte Skript zur Versionsermittlung aus, anstatt den Installationspfad zu erraten. Mit dem Befehl $CATALINA_HOME/bin/version.sh werden die genauen Tomcat- und JVM-Versionen ausgegeben – genau die Daten, die Sie für eine fundierte Bewertung benötigen.

Zuordnung von Versionen zu bekannten CVEs

Vergleichen Sie jede Version mit dem NVD, den Tomcat-Sicherheitshinweisen für Ihren Zweig und dem KEV-Katalog der CISA. Alle Einträge im KEV sollten als aktiv ausgenutzt betrachtet und an den Anfang der Warteschlange verschoben werden.

Überprüfen Sie die Kennzeichen für riskante Konfigurationen

Einige Tomcat-CVEs sind nur dann ausnutzbar, wenn bestimmte Einstellungen aktiviert sind. Überprüfen Sie, ob bei dem Standard-Servlet „readonly“ auf „false“ gesetzt ist, ob „allowPartialPut“ aktiviert ist, ob der AJP-Connector erreichbar ist und ob JNDIRealm, Digest-Authentifizierung oder der EncryptInterceptor überhaupt zum Einsatz kommen. Diese Konfigurationssituation entscheidet darüber, ob eine CVE lediglich vorhanden ist oder tatsächlich ausnutzbar ist.

So beheben und patchen Sie Sicherheitslücken in Apache Tomcat

Das Patchen von Tomcat ist in der Regel unkompliziert, wenn eine korrigierte Version vorliegt. Schwierig wird es bei Servern, bei denen ein Upgrade nicht möglich ist oder deren Version bereits das Ende der Lebensdauer erreicht hat.

Auf eine gepatchte Version aktualisieren

Bei aktiv gepflegten Zweigen sollten Sie auf eine feste Version umsteigen und die Zahlen pro CVE in der obigen Tabelle eher als Mindestanforderung denn als Ziel betrachten. Wählen Sie die aktuellste Version in Ihrem Zweig, was derzeit 9.0.121, 10.1.59 oder 11.0.25 bedeutet. Wenn Sie sich mit der Mindestkorrektur für einen CVE begnügen, behalten Sie alle seitdem veröffentlichten Korrekturen bei. CVE-2026-29146 ist hierfür ein warnendes Beispiel. Die ersten Korrekturen dafür wurden in den Versionen 9.0.116, 10.1.53 und 11.0.20 ausgeliefert, doch alle drei Versionen erwiesen sich als anfällig für die Patch-Umgehung CVE-2026-34486. Daher liegt die tatsächliche Untergrenze hier bei 9.0.117, 10.1.54 oder 11.0.21.

Der CVE-Tracker von TuxCare für Apache Tomcat ist praktisch, um zu überprüfen, welche CVEs eine bestimmte ältere oder EOL-Version betreffen.

Wenden Sie Konfigurationsmaßnahmen an, wenn ein Upgrade noch nicht möglich ist

Falls eine Versionserhöhung noch warten muss, unterbinden Sie den Exploit-Pfad auf der Konfigurationsebene. Behalten Sie die Einstellung „readonly“ auf „true“ für das Standard-Servlet bei – dies ist die Standardeinstellung und hebt die Voraussetzung für ein beschreibbares Servlet automatisch auf. Wenn Schreibzugriffe tatsächlich erforderlich sind, setzen Sie „allowPartialPut“ auf „false“, sofern die Anwendung keine teilweisen Uploads benötigt. Dieser Parameter gibt es bereits seit Jahren, auch in Version 8.5.100 und den älteren 9.0-Builds, sodass er auf nicht gepatchten Servern eine echte Option darstellt. Deaktivieren Sie anschließend den AJP-Connector, wenn Sie ihn nicht verwenden, oder binden Sie ihn an die Schnittstelle, die Ihr Proxy tatsächlich benötigt, und weisen Sie ihm ein Geheimnis zu, falls Sie ihn nutzen.

Achtung: „Partial PUT“ ist standardmäßig aktiviert, die dateibasierte Sitzungspermanenz jedoch nicht – ebenso wenig wie ein beschreibbares Standard-Servlet. Sobald jemand das Standard-Servlet für eine Datei-Upload-Funktion auf „beschreibbar“ umstellt, ist eine der nicht standardmäßigen Voraussetzungen erfüllt. Fügt man die dateibasierte Sitzungspermanenz am Standard-Speicherort und eine Bibliothek hinzu, die zur Deserialisierung missbraucht werden kann, ist die gesamte CVE-2025-24813-Kette aktiv. Betrachtet „Schreibzugriff aktivieren“ als Sicherheitsentscheidung und nicht als Komfortfunktion, und prüft gleichzeitig die beiden anderen Bedingungen, wenn ihr schon dabei seid.

Wählen Sie zwischen manueller und automatischer Patch-Installation und decken Sie EOL-Versionen ab

Wie Sie Patches vornehmen, hängt von der Größe der Flotte ab, davon, welche Anforderungen an die Änderungskontrolle Sie erfüllen müssen, und davon, ob für die Version weiterhin Upstream-Korrekturen bereitgestellt werden.

Tomcat ist ein weitgehend in sich geschlossener Servlet-Container, und die meisten Sicherheitshinweise beziehen sich auf seine eigenen Komponenten wie Catalina, Coyote und Jasper. Bei Produktivbereitstellungen müssen jedoch weiterhin das JDK und alle in der Anwendung enthaltenen Bibliotheken im Blick behalten werden, da diese Abhängigkeiten ihre eigenen Schwachstellen mit sich bringen. In einem Fall wie CVE-2025-24813 ist es zudem eine mitgelieferte Bibliothek, die die Gadget-Kette bereitstellt, durch die unsichere Deserialisierung zur Codeausführung führt.

Wenn Korrekturen aus der Entwicklungskette nicht mehr in die von Ihnen tatsächlich verwendete Version gelangen, kommt der „Endless Lifecycle Support“ von TuxCare für Apache Tomcat ins Spiel. Er portiert CVE-Korrekturen in festgelegte Tomcat-Versionen zurück, die über ein TuxCare-Repository bereitgestellt werden, sodass Sie bei Ihrer aktuellen Version bleiben können, anstatt einen Versionssprung zu vollziehen, den Sie nicht getestet haben. Derzeit umfasst die Abdeckung ausgewählte Tomcat-Versionen der Versionszweige 7, 8.5, 9.0 und 10.1, nämlich 7.0.109, 8.5.100, 9.0.46, 9.0.50, 9.0.75, 9.0.83, 9.0.87, 9.0.90, 9.0.100, 10.1.18 und 10.1.42, und die Dokumentation enthält die aktuelle Matrix. Dieser Bereich ist von Bedeutung, da das Problem nicht nur im Ende des Supportzyklus der jeweiligen Version liegt. Tomcat 7 und 8.5 haben dieses Ende längst überschritten – 8.5 bereits am 31. März 2024 – und für Tomcat 9.0 wurde nun das Ende des Supports für den 31. März 2027 angekündigt. Eine Anwendung, die an eine ältere Version 9.0 oder 10.1 gebunden ist, erhält jedoch nicht die Korrekturen, die Apache in späteren Versionen desselben Zweigs hinzufügt.

Kurz gesagt: Wenn für Ihre Tomcat-Version weiterhin Upstream-Patches bereitgestellt werden, sollten Sie in regelmäßigen Abständen ein Upgrade durchführen. Wenn das Produkt das Ende seines Lebenszyklus erreicht hat oder die Version, an der Sie festhalten, im Upstream-Bereich bereits überholt ist, sollten Sie auf vom Anbieter unterstützte Patches zurückgreifen oder die Migration planen. Eine ungepatchte Version weiter zu betreiben, ist keine Option.

Bewährte Verfahren zur Absicherung von Apache Tomcat

Bei der Absicherung von Tomcat geht es weniger um ausgefallene Kontrollmaßnahmen als vielmehr darum, die sicheren Standardeinstellungen beizubehalten, nicht genutzte Funktionen zu deaktivieren und alle exponierten Bereiche zu sichern. Mit ein paar konsequenten Gewohnheiten lassen sich die meisten gängigen Sicherheitslücken schließen.

Verwenden Sie weiterhin unterstützte Versionen

Verwenden Sie sowohl für Tomcat als auch für das JDK Versionen, für die weiterhin Sicherheitspatches bereitgestellt werden. Für Builds, die vom Upstream-Entwickler nicht mehr unterstützt werden, sorgt der „Endless Lifecycle Support“ für Apache Tomcat dafür, dass weiterhin Patches bereitgestellt werden, ohne dass eine Migration erzwungen wird.

Verbindungen sperren und das Standard-Servlet

Wenden Sie das Prinzip der geringsten Berechtigungen auf die exponierte Oberfläche von Tomcat an. Lassen Sie das Standard-Servlet schreibgeschützt, sofern Sie keinen triftigen Grund haben, dies nicht zu tun, deaktivieren Sie „Partial PUT“, wenn Sie diese Funktion nicht nutzen, und lassen Sie AJP niemals von nicht vertrauenswürdigen Netzwerken aus erreichbar.

Insider-Tipp: Wenn Sie AJP verwenden, binden Sie den Connector an die Schnittstelle, die Ihr vertrauenswürdiger Proxy tatsächlich benötigt, beschränken Sie den Zugriff darauf auf Netzwerkebene und legen Sie ein Passwort fest. Ghostcat war vor allem deshalb so gefährlich, weil dieser Port bei Standardinstallationen weit über ein Jahrzehnt lang offen war.

Stellen Sie Tomcat hinter einen Reverse-Proxy und überwachen Sie es

Bei den meisten Produktionsumgebungen sollten Sie einen gehärteten Reverse-Proxy vor Tomcat schalten, anstatt den Anwendungsconnector direkt freizugeben. Entfernen Sie die Beispielanwendungen und schränken Sie den Zugriff auf die Manager-Anwendung streng ein, falls Sie diese beibehalten. Überwachen Sie die Zugriffsprotokolle auf ungewöhnliche Dateianfragen, insbesondere solche, die den Ordner /WEB-INF/ abtasten oder unerwartete PUT-Anfragen senden.

Schützen Sie Ihren Apache Tomcat mit TuxCare

Sicherheitslücken in Apache Tomcat machen sich selten bemerkbar. Sie schlummern unbemerkt in Standardkonfigurationen und nicht mehr unterstützten Versionen, bis jemand Ihren Server scannt. Die Abhilfe ist zwar langweilig, aber zuverlässig: Sie sollten wissen, welche Software Sie einsetzen, Patches installieren, wo diese verfügbar sind, und für den Rest Abhilfemaßnahmen ergreifen – und niemals eine nicht mehr unterstützte Version ungeschützt lassen. Wenn Sie an einer Version festhängen, die vom Hersteller nicht mehr unterstützt wird, erfahren Sie hier, wie TuxCare einen unbegrenzten Lebenszyklus-Support für Apache Tomcat bietet.

Zusammenfassung

Artikel Name

Was sind Apache-Tomcat-Sicherheitslücken: Erkennung, Behebung und Tipps

Beschreibung

Sorgen Sie für die Sicherheit Ihrer Apache-Tomcat-Server! Erfahren Sie, wie Sie Schwachstellen erkennen, diese beheben und bewährte Verfahren für hohe Sicherheit anwenden.

Autor

Rohan Timalsina

Name des Herausgebers

TuxCare

Logo des Herausgebers