CVE-2025-24813: Apache Tomcat Partial PUT RCE
A critical vulnerability in Apache Tomcat allows unauthenticated remote code execution using just two HTTP requests. The attack exploits Tomcat's partial PUT feature to upload a serialized Java object, then trigger deserialization via a GET request. CVSS 9.8. Affects Tomcat 9, 10, and 11 with default configuration.
| Attribute | Value |
|---|---|
| CVE ID | CVE-2025-24813 |
| CVSS Vector | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| CWE | CWE-502: Deserialization of Untrusted Data |
| Published | March 10, 2025 |
| Exploitation | Active โ public PoC released within 30 hours |
What Is CVE-2025-24813?
Apache Tomcat supports "partial PUT" โ an HTTP feature allowing clients to upload large files in segments using Content-Range headers. Tomcat stores these partial uploads as temporary files in a work directory. The vulnerability arises from two flaws in this implementation:
- The temporary file name is derived from the upload URL path, which is partially attacker-controlled
- If the Java session persistence mechanism is enabled (storing sessions to files), Tomcat may deserialize any file in the work directory that has a
.sessionextension
An attacker can combine these flaws to upload a malicious serialized Java object disguised as a partial upload, then trigger its deserialization by requesting a URL that Tomcat interprets as a session lookup.
๐จ Public PoC Within 30 Hours
A working exploit was published to GitHub approximately 30 hours after CVE-2025-24813 was disclosed. The two-request attack is trivially simple to automate, and mass exploitation campaigns were observed within days. Any unpatched internet-facing Tomcat server with default configuration should be considered compromised.
Affected Versions
| Tomcat Version | Affected Range | Fixed Version |
|---|---|---|
| Apache Tomcat 11.x | 11.0.0-M1 to 11.0.2 | 11.0.3+ |
| Apache Tomcat 10.x | 10.1.0-M1 to 10.1.34 | 10.1.35+ |
| Apache Tomcat 9.x | 9.0.0.M1 to 9.0.98 | 9.0.99+ |
Prerequisites for RCE: Both conditions must be true:
- Default servlet has write enabled (
readonly=false) โ NOT the default; must be explicitly configured - File-based session persistence is configured โ OR partial PUT writes land in a deserialization-accessible path
Note on prerequisites: Some sources initially reported prerequisites were strict. However, real-world analysis showed that certain common Tomcat configurations (including some application server distributions) meet both conditions. Patch regardless โ the CVSS score reflects worst-case conditions.
The Two-Request Attack
# 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
Why Tomcat Is a High-Value Target
Apache Tomcat is one of the most widely deployed Java application servers globally, used in:
- Enterprise Java web applications
- Spring Boot applications deployed as WAR files
- Legacy J2EE applications
- Internal HR, ERP, and business applications
- Cloud-native microservices
An RCE in Tomcat often means access to database credentials, internal APIs, and sensitive business data stored by the applications running on it.
Detection
# 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
- Patch immediately: Upgrade to Tomcat 9.0.99+, 10.1.35+, or 11.0.3+
- Disable default servlet write (if not needed):
<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> - Disable file-based session persistence: Switch to in-memory or database session persistence
- Deploy WAF rules: Block HTTP PUT requests with
Content-Rangeheaders if not needed - Use Java deserialization filters: Configure Java 9+ serialization filters to restrict deserializable classes
KENSAI Detection Capability
- Tomcat version detection: KENSAI fingerprints Apache Tomcat versions from HTTP headers, error pages, and default paths across all internet-facing assets
- Safe exploitation probe: Confirms CVE-2025-24813 exploitability without executing payloads
- Configuration audit: Checks for the presence of write-enabled default servlet and file-based session persistence
- Internal discovery: Finds Tomcat instances running on internal networks via agent or network scanning
- Automated retesting: Confirms patch application after remediation
Find Your Exposed Tomcat Servers Before Attackers Do
KENSAI identifies every Apache Tomcat instance in your environment and tests for CVE-2025-24813 and other critical Java application server vulnerabilities.
Scan for Tomcat Vulnerabilities โ