CVE-2025-24813: Apache Tomcat Partial PUT RCE

Eine kritische Schwachstelle in Apache Tomcat erlaubt unauthentifizierte Remote-Code-Execution mit nur zwei HTTP-Requests. Der Angriff nutzt Tomcats Partial-PUT-Funktion, um ein serialisiertes Java-Objekt hochzuladen und dann über einen GET-Request die Deserialisierung auszulösen. CVSS 9.8. Betrifft Tomcat 9, 10 und 11 in der Standardkonfiguration.

Was ist CVE-2025-24813?

Apache Tomcat unterstützt „Partial PUT“ — eine HTTP-Funktion, die Clients erlaubt, große Dateien segmentweise über Content-Range-Header hochzuladen. Tomcat speichert diese partiellen Uploads als temporäre Dateien in einem Work-Verzeichnis. Die Schwachstelle entsteht aus zwei Fehlern in dieser Implementierung:

1. Der temporäre Dateiname wird aus dem Upload-URL-Pfad abgeleitet, der teilweise angreiferkontrolliert ist
2. Wenn der Java-Session-Persistenz-Mechanismus aktiviert ist (Speichern von Sessions in Dateien), kann Tomcat jede Datei im Work-Verzeichnis deserialisieren, die eine .session-Erweiterung hat

Ein Angreifer kann diese Fehler kombinieren, um ein bösartiges serialisiertes Java-Objekt getarnt als partiellen Upload hochzuladen und dann dessen Deserialisierung auszulösen, indem er eine URL anfragt, die Tomcat als Session-Lookup interpretiert.

Betroffene Versionen

Voraussetzungen für RCE: Beide Bedingungen müssen erfüllt sein:

• Beim Default-Servlet ist Schreiben aktiviert (readonly=false) — NICHT der Standard; muss explizit konfiguriert werden
• Dateibasierte Session-Persistenz ist konfiguriert — ODER Partial-PUT-Schreibvorgänge landen in einem für Deserialisierung erreichbaren Pfad

Der Zwei-Request-Angriff

# Request 1: Upload malicious serialized object as partial PUT
PUT /.xxxxx HTTP/1.1
Host: target.com
Content-Type: application/octet-stream
Content-Range: bytes 0-1233/1234
Content-Length: 1234

[serialized Java gadget chain payload — e.g., Commons Collections]

# Tomcat stores this as a temp file in work directory
# File name derived from URL: .xxxxx → stored as partial upload

# Request 2: Trigger deserialization via session lookup
GET /.xxxxx HTTP/1.1
Host: target.com
Cookie: JSESSIONID=.xxxxx

# Tomcat looks up session file matching the session ID
# Finds attacker's file → deserializes it → RCE

Warum Tomcat ein hochwertiges Ziel ist

Apache Tomcat ist weltweit einer der am weitesten verbreiteten Java-Application-Server und wird eingesetzt in:

• Enterprise-Java-Webanwendungen
• Als WAR-Dateien deployte Spring-Boot-Anwendungen
• Legacy-J2EE-Anwendungen
• Interne HR-, ERP- und Business-Anwendungen
• Cloud-native Microservices

Eine RCE in Tomcat bedeutet oft Zugriff auf Datenbank-Credentials, interne APIs und sensible Geschäftsdaten, die von den darauf laufenden Anwendungen gespeichert werden.

Erkennung

# Check Tomcat version
/opt/tomcat/bin/version.sh
# or check catalina.jar manifest
unzip -p /opt/tomcat/lib/catalina.jar META-INF/MANIFEST.MF | grep Implementation-Version

# Check for suspicious partial PUT uploads in access logs
grep 'PUT' /opt/tomcat/logs/localhost_access_log.* | grep -v '200\|201\|204'
grep 'PUT.*Content-Range' /opt/tomcat/logs/localhost_access_log.*

# Check for unusual files in Tomcat work directory
find /opt/tomcat/work -name "*.session" -newer /opt/tomcat/conf/server.xml
find /opt/tomcat/work -type f -newer /opt/tomcat/conf/server.xml

# Check if default servlet write is enabled
grep -r "readonly" /opt/tomcat/conf/web.xml /opt/tomcat/webapps/

Mitigation

1. Sofort patchen: Upgrade auf Tomcat 9.0.99+, 10.1.35+ oder 11.0.3+
2. Default-Servlet-Schreiben deaktivieren (falls nicht benötigt):

   <servlet>
     <servlet-name>default</servlet-name>
     <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
     <init-param>
       <param-name>readonly</param-name>
       <param-value>true</param-value>  <!-- Ensure this is true -->
     </init-param>
   </servlet>

3. Dateibasierte Session-Persistenz deaktivieren: Wechseln Sie zu In-Memory- oder Datenbank-Session-Persistenz
4. WAF-Regeln einsetzen: Blockieren Sie HTTP-PUT-Requests mit Content-Range-Headern, falls nicht benötigt
5. Java-Deserialisierungs-Filter nutzen: Konfigurieren Sie Java-9+-Serialisierungsfilter, um deserialisierbare Klassen einzuschränken

KENSAI-Erkennungsfähigkeit

• Tomcat-Versionserkennung: KENSAI erkennt Apache-Tomcat-Versionen anhand von HTTP-Headern, Fehlerseiten und Standardpfaden über alle internet-gerichteten Assets hinweg
• Sichere Exploitation-Probe: Bestätigt die Ausnutzbarkeit von CVE-2025-24813, ohne Payloads auszuführen
• Konfigurations-Audit: Prüft auf das Vorhandensein eines schreibfähigen Default-Servlets und dateibasierter Session-Persistenz
• Interne Discovery: Findet Tomcat-Instanzen in internen Netzen via Agent oder Netzwerk-Scanning
• Automatisiertes Retesting: Bestätigt die Patch-Anwendung nach der Remediation