CVE-2025-24813 - Exploiting Path Equivalence and Internal Dots in Apache Tomcat – Remote Code Execution & Sensitive File Disclosure

Apache Tomcat is one of the most popular web servers used around the world, powering everything from development servers to large-scale production services. In February 2025, a major security issue was identified and tracked as CVE-2025-24813. This vulnerability can allow attackers to read sensitive files, inject malicious content, or even launch remote code execution (RCE) attacks — all through a subtle trick in how Tomcat handles file paths with internal dots.

Let's walk through what this vulnerability is, how it can be exploited, example code showing the problem, and, most importantly, how to stay safe.

What’s the Problem? Internal Dot Path Equivalence

The heart of this problem is that certain versions of Tomcat, when configured a particular way, don’t correctly check for "internal dots" (.) in filenames when handling file uploads, especially when those files are written to disk using "partial PUT" requests.

If your server is set up just right (or wrong!), attackers can leverage this mishandled path to

- Write data over sensitive files (info disclosure / content injection)

Partial PUT support is ON (this is enabled by default)

- Security-sensitive upload directory is _under_ a public upload directory (like /uploads/private/ inside /uploads/)

Partial PUT support ON (enabled by default)

- Using Tomcat's file-based session persistence with the default storage location (file-based sessions are kept in work/ by default)

Your app includes a library vulnerable to Java deserialization attacks

> If these match your deployment, PATCH ASAP! Or mitigate (see bottom of this post).

How Does It Work? The Attack Chain

Tomcat’s Default Servlet, when writes are enabled, allows users to upload files using HTTP PUT. With partial PUT, attackers can upload files in parts, resuming or appending as needed.

The issue is that Tomcat does not properly check for internal dot characters in filename paths (for example, file.Name). Attackers can exploit subtle path tricks to:

Gain access to security-sensitive files handled by the same upload code

- Inject serialized Java objects into session storage locations, and trigger deserialization if your app loads sessions from those files

Why Does This Lead to RCE?

1. Upload a malicious serialized Java object into the session store directory (usually work/).

Tomcat may later load that session, triggering your vulnerable library's deserialization code.

3. If deserialization vulnerabilities exist, attacker code executes — potentially full command execution.

Proof-of-Concept: Exploit in Action

Here's a simplified demonstration using curl, assuming a vulnerable Tomcat server.

Suppose the public upload directory is /uploads/ and a security-sensitive file is in /uploads/private/secret.txt.

# Partial PUT - Create (or overwrite) a security file using path trick
curl -X PUT -H "Content-Range: bytes -4/5" \
     --data-binary "hacked" \
     "http://target-server:808/uploads/private/secret.Name";   # The internal '.Name' bypasses checks

# Verify the content
curl "http://target-server:808/uploads/private/secret.txt";

Or, to target Tomcat's session file storage

# Craft or generate a malicious Java serialized payload as payload.ser
# Upload it to the session store location
curl -X PUT --data-binary @payload.ser \
     "http://target-server:808/work/Tomcat/localhost/ROOT/SESSIONS.ser";

# Wait for Tomcat to deserialize and trigger your payload

Note: Path variations and the exact trick may depend on deployment — but the crux is that file.Name might be treated as the real file in certain internal operations, bypassing intended protections.

Links and Further Reading

- Apache Tomcat Security Advisories
- CVE Details: CVE-2025-24813 *(pending update)*
- Full Patch Diff *(placeholder)*
- OWASP: Path Traversal and Equivalence


## How To Fix / Mitigation

Make sure writes are disabled on the Default Servlet (readonly="true" in web.xml)

- Disable partial PUT by configuring the Default Servlet (readonly and/or specifics in your server config)

Do NOT store security-sensitive files in public or user-writeable paths

- Avoid Java file-based session persistence, or move session storage outside web root and public access.

Final Thoughts

While this bug requires a pretty specific setup, the consequences are severe — and the attack is trivial if an attacker lands on the right server configuration. The security implications of path equivalence (with internal dots) are often underestimated.

Always audit your web server’s file write/upload rules, directory layout, and never enable write capabilities broadly unless you know exactly why you need them.

Stay safe! Make sure your Tomcat servers are up to date & properly protected.


Found this useful? Share it with your network and fellow sysadmins. For deeper technical breakdowns and live exploit demos, check the official references above.

Timeline

Published on: 03/10/2025 17:15:35 UTC
Last modified on: 03/12/2025 19:15:38 UTC