Apache Tomcat Default Servlet, partial PUT path-equivalence RCE (Internal Dot)

Overview

CVE-2025-24813 is a critical path-equivalence vulnerability in the write-enabled Default Servlet of Apache Tomcat. Tracked by the Apache classification as Path Equivalence: 'file.Name' (Internal Dot), it lets a remote, unauthenticated attacker reach files outside the intended namespace and, under a specific but realistic configuration, achieve remote code execution on the server's JVM. The NVD assigns a primary CVSS v3.1 base score of 9.8 (Critical).

The Apache Tomcat security team disclosed the issue on 10 March 2025 alongside fixed releases. A public proof of concept appeared within days, and CISA added the CVE to its Known Exploited Vulnerabilities catalog on 1 April 2025, confirming exploitation against internet-facing Tomcat instances. The flaw is notable because the most damaging path, full RCE, does not require the application itself to be vulnerable; it only requires a default-ish combination of Tomcat features and a common deserialization gadget on the classpath.

Technical Details

The root cause is how Tomcat handles partial PUT requests. When partial PUT support is enabled (the default), Tomcat buffers the uploaded byte range in a temporary file whose name is derived from the request URI. Tomcat replaces the path separator in the resource name when generating the temp file name, but an attacker-controlled name containing an internal dot is treated as equivalent to the target resource path. This path-equivalence confusion lets the attacker steer where the buffered content lands.

Two distinct outcomes follow, each gated by its own preconditions. For information disclosure or content injection, all of the following had to be true: writes enabled for the Default Servlet (disabled by default), partial PUT support enabled (enabled by default), a security-sensitive upload target that is a sub-directory of a public upload target, attacker knowledge of the sensitive file names, and those sensitive files also being uploaded via partial PUT. For remote code execution, the conditions are: writes enabled for the Default Servlet, partial PUT enabled, the application using Tomcat's file-based session persistence at the default storage location, and a library on the classpath that can be leveraged in a Java deserialization attack. In the RCE path the attacker uploads a serialized gadget chain as a session file, then triggers deserialization by presenting a crafted session identifier, executing arbitrary code in the broker's process.

Affected versions are Apache Tomcat 9.0.0.M1 through 9.0.98, 10.1.0-M1 through 10.1.34, and 11.0.0-M1 through 11.0.2. The end-of-life 8.5.0 through 8.5.100 line is also known to be affected, and older EOL versions may be as well. The NVD records CWE-502 (Deserialization of Untrusted Data) and CWE-706 (Use of Incorrectly-Resolved Name or Reference).

Impact

• Remote code execution in the Tomcat JVM when write is enabled, partial PUT is on, file-based session persistence uses the default location, and a deserialization gadget is present.
• Disclosure of security-sensitive files (configuration, credentials, keys) uploaded into a sub-directory of a public upload path.
• Injection of attacker-controlled content into those sensitive files, enabling tampering and downstream compromise.
• Full loss of confidentiality, integrity, and availability of the affected application and host (CIA all High).
• No authentication and no user interaction are required, and the attack is fully network-reachable.

Mitigation

1. Upgrade Apache Tomcat to a fixed release: 11.0.3 or later for the 11.0.x branch, 10.1.35 or later for the 10.1.x branch, or 9.0.99 or later for the 9.0.x branch.
2. Migrate off the end-of-life 8.5.x line entirely; 8.5.100 and earlier will not receive a patch.
3. As an interim measure, disable write access for the Default Servlet by ensuring the readonly init-param of org.apache.catalina.servlets.DefaultServlet is true (the default).
4. Disable partial PUT support if write must remain enabled, by setting allowPartialPut to false on the Default Servlet.
5. Avoid file-based session persistence at the default storage location, or relocate and lock down the session store directory so it is not a child of any writable upload path.
6. Audit the classpath and remove deserialization-prone libraries that are not required, reducing the available gadget surface.

Detection

Start at the access logs. Exploitation requires HTTP PUT requests, so any PUT to a Tomcat instance that is not an intentional WebDAV or upload endpoint is immediately suspicious. Grep your access logs for the PUT method and inspect the request targets for resource names that contain an internal dot or that resolve to session storage paths. A partial PUT is identifiable by a Content-Range request header on a PUT; legitimate clients rarely send range-based PUTs, so the presence of Content-Range on PUT against a Tomcat app is a strong indicator worth alerting on.

Look for the two-stage pattern that characterises the RCE chain: an initial PUT (often with Content-Range) that writes a file whose name maps to the session-persistence directory, followed shortly by a normal GET or POST that carries a JSESSIONID cookie matching the just-written file. Correlating the upload of a file to the session directory with a subsequent request referencing that session is the clearest behavioural signature. On the file system, monitor Tomcat's session persistence directory (commonly the work directory or a configured Store path) for the creation of unexpected .session files or files with names that include traversal-style or dotted fragments.

Network detection rules from major vendors are available; ensure your IDS/IPS signatures for CVE-2025-24813 are deployed and that TLS is terminated where the sensor can inspect it, since the attack rides plain HTTP semantics. At the process level, watch the Tomcat JVM for anomalous child processes, since a successful gadget chain typically ends in a Runtime.exec style call; EDR rules that flag the Tomcat process spawning a shell, cmd.exe, powershell, bash, or unexpected network beacons will catch post-exploitation even if the upload itself was missed. Finally, review your configuration to confirm whether you were ever exposed: if readonly was true, partial PUT was disabled, or file-based session persistence was not in use, the RCE path was not reachable, which both lowers urgency and narrows your historical hunt. Retain and re-scan archived logs back to early March 2025, since exploitation was reported within days of disclosure.