Apache Tomcat CVE-2025-24813: Was ist betroffen, wie wird die Schwachstelle ausgenutzt und was ist zu tun?

Wichtigste Erkenntnisse:

• Die Sicherheitslücke CVE-2025-24813 kann es nicht authentifizierten Angreifern ermöglichen, auf Tomcat-Servern Code aus der Ferne auszuführen, Informationen offenzulegen oder Inhalte einzuschleusen – allerdings nur, wenn für das Standard-Servlet Schreibzugriff aktiviert ist (standardmäßig deaktiviert) und einige weitere, vom Standard abweichende Bedingungen erfüllt sind.
• Betroffene Teams sollten ihre Tomcat-Installationen überprüfen, feststellen, ob Sicherheitsbeschränkungen im Einsatz sind, und so schnell wie möglich auf gepatchte Versionen aktualisieren.
• Ältere oder schwer zu aktualisierende Tomcat-Umgebungen erfordern einen klaren Plan zur Risikominderung, anstatt sich auf ungepatchte Versionen zu verlassen, deren Lebensdauer abgelaufen ist.

Wenn Sie Apache-Tomcat-Instanzen in der Produktion verwalten, gehört CVE-2025-24813 zu den Sicherheitslücken, die Ihre sofortige Aufmerksamkeit erfordern. Nicht, weil sie besonders auffällig ist oder Schlagzeilen macht, sondern weil sie ein echtes, ausnutzbares Risiko in Konfigurationen darstellt, die überraschend häufig vorkommen.

Hier geht es nicht um einen theoretischen Sonderfall, der nur jemanden betrifft, der Tomcat auf einem Raspberry Pi im Debug-Modus ausführt. Wir sprechen von einer Sicherheitslücke, die reale Produktionsumgebungen betreffen kann und Angreifern möglicherweise einen Zugang zu Ihrer Anwendungsinfrastruktur verschafft. Lassen Sie uns einmal genauer betrachten, was CVE-2025-24813 eigentlich ist, wer sich darüber Gedanken machen muss und wie man das Problem beheben kann, ohne dass Ihre Woche zur Krisensituation wird.

Was ist CVE-2025-24813?

CVE-2025-24813 ist eine Schwachstelle im Zusammenhang mit Pfadäquivalenz in Apache Tomcat, die zur Ausführung von Code aus der Ferne ohne Authentifizierung, zur Offenlegung von Informationen oder zur Einfügung von Inhalten in hochgeladene Dateien führen kann. In der Praxis kann ein Angreifer, der Zugriff auf eine anfällige Tomcat-Instanz hat, möglicherweise eine schädliche Datei hochladen und Tomcat dazu bringen, diese auszuführen – ohne dass Anmeldedaten erforderlich sind.

Die Sicherheitslücke ergibt sich aus der Art und Weise, wie die Teil-PUT-Verarbeitung von Tomcat temporäre Dateipfade bildet. Die ursprüngliche Implementierung erzeugte einen temporären Dateinamen auf der Grundlage des vom Benutzer angegebenen Dateinamens und Pfads, wobei das Pfadtrennzeichen durch einen Punkt ersetzt wurde. In Verbindung mit der dateibasierten Sitzungspermanenz von Tomcat ermöglicht dieses Design einem Angreifer, eine manipulierte, serialisierte Java-Nutzlast in das Sitzungsverzeichnis hochzuladen und anschließend die Deserialisierung mit einer nachfolgenden GET-Anfrage auszulösen, die eine passende JSESSIONID auszulösen. Das Ergebnis ist die Ausführung von Remote-Code.

Besonders besorgniserregend ist dabei, dass keine Authentifizierung erforderlich ist und die Nutzlast Base64-kodiert werden kann, um gängige Erkennungsregeln zu umgehen. Sobald ein Angreifer die Dateipfadkollision und den Auslöser für die Deserialisierung verstanden hat, ist die Ausnutzung ein reiner Routinevorgang.

Allerdings gibt es für diese Sicherheitslücke konkrete Voraussetzungen. Damit sie ausgenutzt werden kann, müssen alle folgenden Bedingungen erfüllt sein: Schreibzugriff auf das Standard-Servlet ist aktiviert (standardmäßig deaktiviert – das readonly in conf/web.xml muss auf false), ist Tomcat so konfiguriert, dass es die dateibasierte Sitzungspermanenz verwendet (nicht die Standardeinstellung), und der Klassenpfad der Anwendung enthält eine Deserialisierungs-Gadget-Kette, die der Angreifer ausnutzen kann. Genau aus diesem Grund stufte Apache die CVE zunächst als „wichtig“ und nicht als „kritisch“ ein. Sind jedoch alle Voraussetzungen erfüllt, führt dies zu einer vollständigen Kompromittierung des Servers – und die CISA nahm die Schwachstelle innerhalb weniger Wochen nach ihrer Offenlegung in den Katalog der bekannten ausgenutzten Schwachstellen auf. – 

Welche Tomcat-Versionen sind betroffen?

CVE-2025-24813 betrifft mehrere Zweige von Apache Tomcat, wobei der genaue Bereich der anfälligen Versionen davon abhängt, welche Hauptversion Sie verwenden. Hier ist die Aufschlüsselung:

• Apache Tomcat 11.0.x weist in den Versionen 11.0.0-M1 bis 11.0.2 eine Sicherheitslücke auf. Der Fix wurde in 11.0.3, Sie müssen also mindestens Version 11.0.3 verwenden, um den Patch zu erhalten.
• Apache Tomcat 10.1.x ist in den Versionen 10.1.0-M1 bis 10.1.34 anfällig. Der Fix ist in 10.1.35 und nachfolgenden Versionen enthalten.
• Apache Tomcat 9.0.x ist in den Versionen 9.0.0.M1 bis 9.0.98 anfällig. Sie benötigen Version 9.0.99 oder höher, um die Sicherheitslücke zu beheben.
• Apache Tomcat 8.5.x hat am 31. März 2024 das Ende der Lebensdauer erreicht, noch bevor diese CVE bekannt wurde. Das Apache Tomcat-Projekt hat keinen Community-Patch für 8.5 veröffentlicht, sodass jede 8.5.x-Bereitstellung dauerhaft gefährdet ist, es sei denn, Sie migrieren zu einem unterstützten Zweig oder erhalten Schutz durch einen kommerziellen Anbieter von erweitertem Support.

Insbesondere Tomcat 8.5 und alle älteren Versionen – die Zweige 8.0.x und 7.0.x – haben das Ende ihrer Lebensdauer erreicht und erhalten keinen Community-Patch für CVE-2025-24813. Wenn Sie einen dieser Zweige verwenden, haben Sie nur zwei Möglichkeiten: Entweder Sie migrieren auf eine unterstützte Version oder Sie sichern sich Schutz durch einen kommerziellen Anbieter für erweiterten Support. Auf beides werden wir gleich noch näher eingehen.

Man muss sich vor allem bewusst machen, dass dies nicht nur die allerneuesten Versionen oder obskure Konfigurationen betrifft. Die Sicherheitslücke betrifft alle wichtigen Tomcat-Versionen, die derzeit aktiv in der Produktion eingesetzt werden, einschließlich der etablierten Versionszweige 9.0 und 8.5, auf denen unzählige Unternehmensanwendungen laufen.

Das Ausnutzungsszenario verstehen

Um das Risiko wirklich einzuschätzen, muss man verstehen, wann und wie sich diese Schwachstelle in Produktionsumgebungen tatsächlich auswirkt.

Das Ausnutzungsszenario für CVE-2025-24813 dreht sich um das Standard-Servlet von Tomcat – die Komponente, die direkte Dateianfragen verarbeitet – und eine Funktion namens „Partial PUT“, die es Clients ermöglicht, Teile einer Datei über mehrere Anfragen hinweg hochzuladen. Standardmäßig ist das Standard-Servlet schreibgeschützt und ignoriert PUT-Anfragen vollständig, weshalb die meisten Installationen nicht gefährdet sind. Die Sicherheitslücke wird nur dann ausnutzbar, wenn ein Administrator die readonly auf false in conf/web.xmlund aktivieren Sie so das Hochladen über das Standard-Servlet.

Jetzt wird es interessant: Selbst wenn Schreibzugriffe aktiviert sind, sind für die Ausnutzung des Schwachpunkts noch weitere Voraussetzungen erforderlich. Tomcat muss für die dateibasierte Sitzungsspeicherung konfiguriert sein (die FileStore Manager anstelle von In-Memory-Sitzungen), der Klassenpfad der Anwendung muss eine Deserialisierungs-Gadget-Kette enthalten, und der Angreifer muss in der Lage sein, den Upload-Endpunkt über das Netzwerk zu erreichen.

Wenn diese Bedingungen erfüllt sind, ist die Angriffskette kurz. Der Angreifer sendet eine partielle PUT-Anfrage, die eine serialisierte Java-Nutzlast in einen von ihm kontrollierten Pfad hochlädt. Da die Implementierung des partiellen PUT in Tomcat die Anfrage-URI in einen temporären Dateinamen übersetzt – wobei Pfadtrennzeichen durch Punkte ersetzt werden –, landet die hochgeladene Datei genau dort, wo Tomcat später nach Sitzungsdaten sucht. Eine nachfolgende GET-Anfrage mit einem manipulierten JSESSIONID veranlasst Tomcat dazu, die Datei zu deserialisieren, die Gadget-Kette auszuführen und dem Angreifer die Ausführung von Remote-Code zu ermöglichen. In keinem Schritt ist eine Authentifizierung erforderlich.

In der Praxis bedeutet das nicht, dass „ein Angreifer einen zusätzlichen Endpunkt sehen kann“. Es bedeutet vielmehr, dass „ein Angreifer eine Payload hochlädt, eine weitere Anfrage sendet und Code als Tomcat-Prozess ausführt“.

Wenn Ihre Anwendung keine Schreibzugriffe auf das Standard-Servlet zulässt oder keine dateibasierte Sitzungsspeicherung verwendet, sind Sie nicht von der Schwachstelle betroffen, die die Ausführung von Remote-Code ermöglicht. Unter leicht abweichenden Bedingungen könnten Sie jedoch weiterhin von den Varianten „Informationsoffenlegung“ oder „Inhaltsinjektion“ betroffen sein; daher ist die Installation des Patches nach wie vor die richtige Entscheidung – die Dringlichkeit hängt jedoch vollständig von Ihrer Konfiguration ab.

Einschätzung Ihres Risikos

Bevor Sie mit der Installation der Patches beginnen, sollten Sie sich einen Moment Zeit nehmen, um zu prüfen, ob Ihre spezifischen Tomcat-Installationen tatsächlich durch CVE-2025-24813 gefährdet sind.

• Überprüfen Sie zunächst Ihre Tomcat-Versionen. Das klingt selbstverständlich, aber in komplexen Umgebungen mit mehreren Tomcat-Instanzen werden Sie überrascht sein, wie oft Teams keine vollständige Bestandsliste haben. Wenn Sie eine Version verwenden, die älter ist als die zuvor aufgeführten gepatchten Versionen, sind Sie potenziell anfällig. Vergessen Sie nicht die Tomcat-Instanzen, die in Docker-Containern laufen, in Microservice-Bereitstellungen versteckt sind oder in andere Anwendungen eingebettet sind.
• Second, review your security constraint configurations. Look at the ‘web.xml’ files (and any programmatic security configurations) for your deployed applications. Are you using ‘<security-constraint>’ elements to protect resources? Are you relying on Tomcat’s built-in authentication mechanisms? If the answer is yes, you need to treat this vulnerability seriously.
• Drittens sollten Sie Ihre Bereitstellungsarchitektur berücksichtigen. Sind Ihre Tomcat-Instanzen direkt mit dem Internet verbunden oder befinden sie sich hinter Reverse-Proxys, API-Gateways oder anderen Sicherheitsschichten? Auch wenn eine mehrschichtige Verteidigung immer sinnvoll ist, sollten Sie nicht davon ausgehen, dass ein WAF oder ein Reverse-Proxy Sie automatisch vor dieser Schwachstelle schützt. Die zur Ausnutzung von CVE-2025-24813 erforderliche Manipulation von Anfragen könnte diese Schichten problemlos passieren.
• Denken Sie schließlich darüber nach, was Sie eigentlich schützen. Selbst wenn Sie technisch anfällig sind, hängt das tatsächliche Risiko davon ab, worauf ein Angreifer Zugriff erhalten könnte, wenn er Ihre Sicherheitsbeschränkungen umgeht. Handelt es sich um eine Admin-Oberfläche mit Zugriff auf Kundendaten oder Systemsteuerungen, steht viel auf dem Spiel. Ist es hingegen ein interner Überwachungsendpunkt, der nur bereinigte Kennzahlen anzeigt, sieht die Dringlichkeit anders aus.

Es geht hier nicht darum, die Sicherheitslücke herunterzuspielen oder sich selbst davon abzubringen, das Patch zu installieren. Vielmehr geht es darum, Ihr Risikoprofil zu verstehen, damit Sie die Abhilfemaßnahmen angemessen priorisieren können, insbesondere wenn Sie Dutzende oder Hunderte von Tomcat-Instanzen verwalten.

Maßnahmen zur Risikominderung und Fehlerbehebung

Die wichtigste und empfohlene Abhilfe für CVE-2025-24813 ist einfach: Führen Sie ein Upgrade auf eine gepatchte Version von Apache Tomcat durch. Doch wie jeder weiß, der bereits Tomcat-Produktionsumgebungen verwaltet hat, ist „einfach ein Upgrade durchführen“ leichter gesagt als getan.

Der saubere Upgrade-Pfad

Wenn ein sauberes Upgrade möglich ist, sieht das folgendermaßen aus:

• Ermitteln Sie Ihre aktuelle Tomcat-Version in allen Bereitstellungen. Verwenden Sie catalina.sh version oder überprüfen Sie die Versionsnummer in Ihrem Tomcat-Installationsverzeichnis. Verlassen Sie sich nicht auf Dokumentation oder Runbooks, die möglicherweise veraltet sind.
• Laden Sie die entsprechende gepatchte Version von der offiziellen Apache Tomcat-Website herunter. Für Tomcat 11 benötigen Sie Version 11.0.3 oder höher. Für 10.1 benötigen Sie Version 10.1.35 oder höher. Für 9.0 benötigen Sie Version 9.0.99 oder höher. Wenn Sie noch Tomcat 8.5 verwenden, gibt es keinen Community-Patch – siehe „Wenn ein Upgrade nicht sofort möglich ist“ weiter unten. Laden Sie die Software immer von offiziellen Quellen herunter, niemals von beliebigen Spiegelseiten oder Repositorys von Drittanbietern.
• Testen Sie das Upgrade zunächst in einer Nicht-Produktionsumgebung. Das ist keine unnötige Vorsicht – es ist grundlegende Betriebshygiene. Tomcat-Upgrades führen gelegentlich zu Verhaltensänderungen oder Leistungsmerkmalen, die Sie überraschen können. Vergewissern Sie sich, dass Ihre Anwendungen weiterhin funktionieren, dass die Leistungskennzahlen angemessen sind und dass alle Überwachungs- oder Protokollierungsintegrationen weiterhin funktionieren.
• Planen Sie die Einführung in der Produktion. Berücksichtigen Sie Ihre Bereitstellungsfenster, Verkehrsmuster und Rollback-Verfahren. Wenn Sie Tomcat hinter einem Load Balancer betreiben, können Sie die Instanzen nacheinander aktualisieren. Wenn Sie sich in einer eingeschränkteren Umgebung befinden, benötigen Sie möglicherweise ein Wartungsfenster. Stellen Sie sicher, dass Sie über einen getesteten Rollback-Plan verfügen, falls etwas schiefgeht.
• Führen Sie das Upgrade durch und überprüfen Sie, ob Sie die gepatchte Version verwenden. Gehen Sie nicht einfach davon aus, dass das Upgrade funktioniert hat – überprüfen Sie die Versionsnummer nach der Bereitstellung.

Konfigurationsbasierte Abhilfemaßnahmen

Ein Upgrade ist zwar die richtige Lösung, doch gibt es möglicherweise Konfigurationsänderungen, mit denen Sie Ihr Risiko kurzfristig verringern können. Überprüfen Sie Ihre Sicherheitsbeschränkungen, um sicherzustellen, dass sie so spezifisch und restriktiv wie möglich sind. Zu weit gefasste URL-Muster oder vage definierte Beschränkungen können Ihre Angriffsfläche vergrößern.

Erwägen Sie die Implementierung zusätzlicher Authentifizierungsebenen auf der Ebene des Reverse-Proxys oder des API-Gateways, sofern Ihre Architektur über diese Komponenten verfügt. Auch dies ist kein Ersatz für die Installation von Patches, trägt jedoch zu einer mehrschichtigen Verteidigung bei.

Wenn Sie Tomcat-Instanzen betreiben, auf denen mehrere Webanwendungen gehostet werden, sollten Sie überprüfen, welche Anwendungen bereitgestellt sind und ob sie alle wirklich erforderlich sind. Durch die Reduzierung der Anzahl der bereitgestellten Anwendungen verringern Sie die potenzielle Angriffsfläche.

Betriebliche Überlegungen

Hier sind einige praktische Punkte, auf die Sie während des Patch-Vorgangs achten sollten:

• Anforderungen für den Neustart. Ein Upgrade von Tomcat erfordert einen Neustart. Das bedeutet Ausfallzeiten für Ihre Anwendungen, es sei denn, Sie haben Ihre Architektur für Bereitstellungen ohne Ausfallzeiten ausgelegt. Planen Sie entsprechend.
• Kompatibilität der Konfigurationsdateien. Die meisten Tomcat-Upgrades sind abwärtskompatibel mit bestehenden Konfigurationsdateien, jedoch nicht immer. Achten Sie besonders auf alle Anpassungen, die Sie an server.xml, web.xmloder anderen Konfigurationsdateien.
• Abhängigkeiten hinsichtlich der JVM-Version. Verschiedene Tomcat-Versionen stellen unterschiedliche Anforderungen an die Java-Version. Tomcat 10.1 erfordert Java 11. Tomcat 11 erfordert Java 17 oder höher. Wenn Sie ein Upgrade von einer älteren Tomcat-Version durchführen, müssen Sie möglicherweise auch Ihre JVM aktualisieren, was den Vorgang komplexer macht.
• Kompatibilität von Bibliotheken und Konnektoren. Wenn Sie JDBC-Treiber, JMS-Konnektoren oder andere Bibliotheken mit Tomcat verwenden, stellen Sie sicher, dass diese mit der Version kompatibel sind, auf die Sie aktualisieren. Dies ist besonders wichtig für ältere Unternehmensanwendungen.
• Überwachungs- und APM-Agenten. Wenn Sie Überwachungsagenten oder APM-Tools einsetzen, die in Tomcat eingebunden sind, überprüfen Sie, ob diese nach dem Upgrade weiterhin funktionieren. Einige Agenten reagieren empfindlich auf Änderungen der Tomcat-Version.

Wenn ein Upgrade nicht sofort möglich ist

Seien wir realistisch: Nicht jedes Unternehmen kann alles stehen und liegen lassen und alle Tomcat-Instanzen sofort aktualisieren, sobald eine CVE veröffentlicht wird. Manchmal hat man es mit Anwendungen von Anbietern zu tun, die bestimmte Tomcat-Versionen enthalten und neuere Versionen nicht unterstützen. Manchmal laufen Legacy-Anwendungen auf älteren Tomcat-Zweigen, deren Aktualisierung umfangreiche Tests und Validierungen erfordern würde. Manchmal sind die Ressourcen einfach begrenzt und man muss den kritischsten Instanzen Vorrang einräumen.

Für Teams, die ältere Tomcat-Versionen einsetzen, die nicht sofort aktualisiert werden können, gibt es Optionen für einen erweiterten Sicherheitssupport, um diese Lücke zu überbrücken. Dienste wie der „Endless Lifecycle Support“ (ELS) von TuxCare bieten fortlaufende Sicherheitspatches für Softwareversionen, deren Lebenszyklus abgelaufen ist, darunter auch ältere Tomcat-Versionen, für die vom Apache-Projekt keine Updates mehr bereitgestellt werden.

Dies ist kein Ersatz für ordnungsgemäße Patches und Upgrades auf aktuelle Versionen. Es handelt sich um eine pragmatische Option zur Risikominderung, die Teil eines schrittweisen Sanierungsplans sein kann. Wenn Sie Tomcat-8.0- oder 7.0-Instanzen betreiben, die nicht sofort migriert werden können, kann der erweiterte Support diese Systeme vor bekannten Sicherheitslücken schützen, während Sie den Upgrade-Prozess innerhalb eines realistischen Zeitrahmens durchführen.

Entscheidend ist, dass man dabei bewusst vorgeht. Wenn Sie den erweiterten Support nutzen, sollten Sie einen klaren Plan für den späteren Umstieg auf aktuelle Tomcat-Versionen haben. Lassen Sie den erweiterten Support nicht zu einer Ausrede werden, um technische Schulden auf unbestimmte Zeit aufzuschieben.

Über diese CVE hinaus: Aufbau robuster Tomcat-Bereitstellungen

CVE-2025-24813 ist zwar nur eine einzelne Sicherheitslücke, doch sie ist Teil eines größeren Musters. Tomcat-Sicherheitslücken werden regelmäßig entdeckt, und das wird auch immer so bleiben. Die Frage ist nicht, ob Sie Tomcat erneut patchen müssen – sondern wie schnell und reibungslos Sie dies tun können, wenn die nächste CVE-Meldung erscheint.

Das bedeutet, Betriebsabläufe zu etablieren, die eine schnelle Installation von Patches ermöglichen: die Führung übersichtlicher Bestandslisten aller Tomcat-Bereitstellungen, erprobte Upgrade-Verfahren, regelmäßige Schwachstellenscans sowie die Einrichtung von Staging-Umgebungen, die die Produktionsumgebung widerspiegeln, um Updates zu testen.

Das bedeutet auch, architektonische Entscheidungen zu treffen, die die Sicherheit fördern: Tomcat-Instanzen hinter Reverse-Proxys zu betreiben, Netzwerksegmentierung zu implementieren, Container-Orchestrierung zu nutzen, die rollierende Updates erleichtert, und bei den Berechtigungen für Tomcat-Prozesse das Prinzip der geringsten Privilegien zu befolgen.

Und das bedeutet, stets auf dem Laufenden zu bleiben. Abonnieren Sie die Apache Tomcat-Sicherheitsmailingliste. Beobachten Sie CVE-Datenbanken auf Tomcat-bezogene Sicherheitslücken. Warten Sie nicht, bis eine Sicherheitslücke öffentlich bekannt wird, bevor Sie mit der Planung Ihrer Reaktion beginnen.

Maßnahmen ergreifen

CVE-2025-24813 ist zwar schwerwiegend, lässt sich aber beheben. Es gibt bereits Patches, die Maßnahmen zur Risikominderung sind klar definiert, und die Voraussetzungen für eine Ausnutzung sind so spezifisch, dass Sie fundierte Entscheidungen hinsichtlich der Priorisierung treffen können.

Wenn Sie betroffene Tomcat-Versionen einsetzen und Ressourcen durch Sicherheitsbeschränkungen schützen, sollten Sie dies als eine Patching-Aufgabe mit hoher Priorität behandeln. Testen Sie das Upgrade, planen Sie die Einführung und aktualisieren Sie die betreffenden Instanzen. Wenn Sie ältere Tomcat-Versionen einsetzen, für die keine Patches mehr bereitgestellt werden, prüfen Sie Ihre Optionen für einen erweiterten Support oder beschleunigen Sie Ihre Migrationspläne.

Die schlechteste Reaktion auf CVE-2025-24813 ist, das Problem zu ignorieren und zu hoffen, dass es keine Rolle spielt. Die beste Reaktion besteht darin, das Ausmaß der Gefährdung zu erfassen, die Abhilfemaßnahmen nach Priorität zu ordnen und die Patches systematisch zu installieren.

Ihre Tomcat-Instanzen sind Teil Ihrer Anwendungsinfrastruktur. Für deren Sicherheit zu sorgen, ist keine optionale Aufgabe, die man nebenbei erledigt, wenn gerade Zeit dafür ist. Es handelt sich um eine zentrale betriebliche Verantwortung, die Zeit, Aufmerksamkeit und Ressourcen verdient.

Zusammenfassung

Artikel Name

Apache Tomcat CVE-2025-24813

Beschreibung

Die Sicherheitslücke CVE-2025-24813 kann es nicht authentifizierten Angreifern ermöglichen, auf Tomcat-Servern Code aus der Ferne auszuführen oder Inhalte einzuschleusen. Weiterlesen

Autor

Tim Walker

Name des Herausgebers

TuxCare

Logo des Herausgebers