CVE Deep Dive: How Apache Tomcat's Partial PUT Flaw Lets Attackers Take Over Your Server

1. The Bug — Root Cause

Apache Tomcat's DefaultServlet handles static file serving. It also supports HTTP partial PUT — a mechanism where a client can upload a file in segments by appending a suffix to the request path. The flaw lives in how Tomcat resolves the target path during a partial PUT when the servlet's readonly parameter is set to false.

Here's the vulnerable configuration that enables the attack:​‌‌​​​‌‌‍​‌‌‌​‌‌​‍​‌‌​​‌​‌‍​​‌​‌‌​‌‍​‌‌​​‌​​‍​‌‌​​‌​‌‍​‌‌​​‌​‌‍​‌‌‌​​​​‍​​‌​‌‌​‌‍​‌‌​​‌​​‍​‌‌​‌​​‌‍​‌‌‌​‌‌​‍​‌‌​​‌​‌‍​​‌​‌‌​‌‍​‌‌​​​​‌‍​‌‌‌​​​​‍​‌‌​​​​‌‍​‌‌​​​‌‌‍​‌‌​‌​​​‍​‌‌​​‌​‌‍​​‌​‌‌​‌‍​‌‌‌​‌​​‍​‌‌​‌‌‌‌‍​‌‌​‌‌​‌‍​‌‌​​​‌‌‍​‌‌​​​​‌‍​‌‌‌​‌​​‍​​‌​‌‌​‌‍​‌‌‌​​‌​‍​‌‌​​​‌‌‍​‌‌​​‌​‌‍​​‌​‌‌​‌‍​‌‌​​‌​‌‍​‌‌‌‌​​​‍​‌‌‌​​​​‍​‌‌​‌‌​​‍​‌‌​‌‌‌‌‍​‌‌​‌​​‌‍​‌

‌‌​‌​​‍​‌‌​​​​‌‍​‌‌‌​‌​​‍​‌‌​‌​​‌‍​‌‌​‌‌‌‌‍​‌‌​‌‌‌​‍​​‌​‌‌​‌‍​‌‌‌​‌‌‌‍​‌‌​​​​‌‍​‌‌​‌‌​​‍​‌‌​‌​‌‌‍​‌‌‌​‌​​‍​‌‌​‌​​​‍​‌‌‌​​‌​‍​‌‌​‌‌‌‌‍​‌‌‌​‌​‌‍​‌‌​​‌‌‌‍​‌‌​‌​​​

<!-- web.xml or default servlet init-param -->
<servlet>
  <servlet-name>default</servlet-name>
  <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
  <init-param>
    <param-name>readonly</param-name>
    <param-value>false</param-value>  <!-- THIS IS THE ENABLER -->
  </init-param>
</servlet>

When readonly is false, Tomcat permits PUT and DELETE on the default servlet. The partial PUT implementation constructs the target file path by stripping the upload suffix from the request URI. If an attacker sends a PUT to a path ending in the upload suffix, Tomcat writes the payload to a calculated location on disk. The problem: Tomcat does not validate that the resolved path lands in a safe directory, and it does not sanitise the content before writing it as a serialised Java object.

The vulnerable code path in DefaultServlet.doPut() calls recombinePartialPutFile(), which reads the uploaded bytes and writes them to the resolved path — without restricting file extensions, directories, or content type.

2. The Exploit — What an Attacker Chains Together

The full exploitation chain has three stages:

Stage 1 — Upload a gadget chain payload. The attacker sends a partial PUT request containing a malicious serialised Java object. Libraries like Commons Collections, Commons BeanUtils, or Spring framework on the classpath provide "gadget chains" — sequences of Java classes whose deserialization triggers arbitrary method calls, culminating in Runtime.exec().

PUT /uploads/../../session.ser/<upload-suffix> HTTP/1.1
Host: target.com.au
Content-Type: application/java-serialized-object
Content-Length: 2847

[serialised ysoserial CommonsCollections6 payload]

The path traversal component (../../) means the attacker can write the serialised payload into directories the application later reads from — specifically, Tomcat's session persistence directory or a classpath-accessible location.

Stage 2 — Trigger deserialization. Tomcat's session manager persists HTTP sessions to disk as serialised Java objects. When an attacker can place a .ser file in the session storage path, Tomcat deserialises it automatically when it attempts to load that session — no user interaction required beyond a request with the matching JSESSIONID.

Stage 3 — Achieve RCE. The gadget chain executes during deserialization, running arbitrary OS commands as the Tomcat process user (often root in poorly configured SMB deployments).

The entire chain requires: readonly=false on the default servlet, a gadget chain library on the classpath, and a reachable Tomcat instance. No authentication is needed.

3. The Blast Radius — Who's Actually Vulnerable

For Australian SMBs, the risk profile breaks down like this:

High risk:

• Any Tomcat deployment where someone changed readonly to false — this is sometimes done to enable file upload via WebDAV-style PUT, and is common in older internal apps and hastily deployed proof-of-concept projects
• Spring Boot applications bundled with embedded Tomcat that include Commons Collections in their dependency tree (very common)
• Internet-facing Tomcat instances on ports 8080/8443 without a WAF or reverse proxy filtering PUT methods

Elevated risk:

• Internal Tomcat apps behind VPNs — lateral movement after initial access makes these exploitable during broader intrusions
• Tomcat instances running as root — RCE becomes full system compromise

Lower risk but not zero:

• Default Tomcat installations where readonly remains true — the vulnerability exists but the primary exploitation path is blocked. However, security researchers have identified secondary paths involving specific servlet configurations

According to Shodan data, over 800,000 Tomcat instances are publicly reachable. Australian government and SMB infrastructure accounts for a meaningful slice — particularly healthcare, education, and local government sectors running legacy Java applications.

4. The Patch — What the Vendor Fix Does

Apache patched this in Tomcat versions 9.0.99, 10.1.35, and 11.0.2. The fix has two components:

1. Path validation in recombinePartialPutFile() — the resolved target path is now checked against the allowed upload directory. Path traversal via ../ sequences is rejected before any file write occurs.

2. Content type restriction — partial PUT requests with Content-Type: application/java-serialized-object are now explicitly blocked by the default servlet when readonly=false.

The patch is minimal and surgical — it doesn't change the partial PUT mechanism itself, just hardens the validation around it. This means existing legitimate file upload workflows are unaffected.

Action for SMBs:

# Check your Tomcat version
./catalina.sh version

# If below 9.0.99 / 10.1.35 / 11.0.2, upgrade immediately
# On Ubuntu/Debian:
sudo apt update && sudo apt install libtomcat9-java tomcat9

# Verify readonly is true (default) in all deployed web.xml files:
grep -r "readonly" /etc/tomcat9/ /var/lib/tomcat9/webapps/*/WEB-INF/web.xml

5. Detection — Log Lines, Indicators, and Sigma Rules

Apache Tomcat Access Log Indicators

Look for these patterns in /var/log/tomcat9/localhost_access_log.*:

192.168.x.x - - [24/Apr/2026:03:14:22 +1000] "PUT /uploads/../../work/Catalina/localhost/_/SESSIONS.ser/upload_abc123 HTTP/1.1" 204 -
192.168.x.x - - [24/Apr/2026:03:14:22 +1000] "PUT /context/../sessions.ser/upload HTTP/1.1" 201 -

Key indicators: PUT method, path traversal sequences (../), .ser or .session in the URL, and content type application/java-serialized-object.

Nginx Reverse Proxy Filter (if fronting Tomcat)

# Block suspicious PUT requests before they reach Tomcat
if ($request_method = PUT) {
    set $block_put 1;
}
if ($uri ~* "\.\./|\.ser|\.session") {
    set $block_put "${block_put}1";
}
if ($block_put = "11") {
    return 403;
}

Sigma Rule

title: Apache Tomcat Partial PUT RCE CVE-2025-24813
id: a7c3f1e2-4b5d-6789-abcd-ef0123456789
status: stable
description: Detects exploitation of CVE-2025-24813 via partial PUT with path traversal
author: lil.business
date: 2026/04/24
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-24813
logsource:
    category: webserver
    product: apache_tomcat
detection:
    selection_method:
        cs-method: 'PUT'
    selection_path:
        cs-uri|contains:
            - '../'
            - '..\'
            - '.ser'
    selection_content:
        sc-status:
            - 200
            - 201
            - 204
    condition: selection_method and selection_path and selection_content
level: critical
tags:
    - attack.initial_access
    - attack.t1190
    - cve.2025-24813

Crowdsec Scenario

If you're running Crowdsec in front of Tomcat (recommended for Australian SMBs wanting community threat intelligence):

sudo cscli collections install crowdsecurity/http-cve
sudo cscli decisions list  # review blocked IPs after deployment

The http-cve collection includes detection patterns for partial PUT abuse and path traversal in Tomcat contexts.

FAQ

Conclusion

CVE-2025-24813 is a textbook example of how a single configuration change (readonly=false) can transform a well-understood servlet into a remote code execution vector. The exploitation chain is reliable, the prerequisites are common in real-world deployments, and the impact is full server compromise. For Australian SMBs running Java applications — particularly in healthcare, education, and local government — this is the kind of vulnerability that warrants immediate verification, not quarterly patching cycles.

Your action items: audit all Tomcat instances for readonly=false, verify versions against the patched releases, deploy the Sigma rule above to your SIEM or log aggregation system, and block PUT methods at the reverse proxy layer as a defence-in-depth measure.

Visit consult.lil.business for a free cybersecurity assessment — we'll check your exposed services, identify vulnerable configurations, and give you a prioritised remediation plan in plain English.

References

1. NVD — CVE-2025-24813 Detail
2. Apache Tomcat Security Advisories
3. Australian Cyber Security Centre — Vulnerability Disclosure Guidance
4. SANS — Java Deserialization Attack Chain Analysis