Security Digest · Mar 10, 2025 · Vulnerability · Web framework

Apache Tomcat Partial PUT RCE (CVE-2025-24813)

Tomcat 9.0.98/10.1.34/11.0.2 and older could be hit via partial PUT only if default-servlet writes were enabled. Fixed in 9.0.99/10.1.35/11.0.3. Most can relax.

Our verdict

Most can relax

It is in KEV and attacks were seen within days, but exploitation needs the default servlet's write support turned on, which is off by default and rare; upgrade on your normal cycle and check that one setting.

Who must act: Tomcat deployments where the DefaultServlet has readonly set to false, especially combined with file-based session persistence (PersistentManager + FileStore).

Who can relax: The large majority of Tomcat users, who never enabled default-servlet writes, and anyone already on 9.0.99, 10.1.35, 11.0.3 or later.

Affected
Apache Tomcat 11.0.0-M1 through 11.0.2
Apache Tomcat 10.1.0-M1 through 10.1.34
Apache Tomcat 9.0.0.M1 through 9.0.98
Apache Tomcat 8.5.0 through 8.5.100 (EOL, known affected)
Fixed in
Apache Tomcat 11.0.3
Apache Tomcat 10.1.35
Apache Tomcat 9.0.99
CVSS
10.0 (v3.1, CISA ADP)
EPSS
99.9% (percentile 100.0)
CISA KEV
Yes, listed as known exploited
Exploitation
Exploited in the wild
Severity
Critical

What to do

  1. Check your version: run bin/version.sh (or catalina.sh version) and upgrade to 11.0.3, 10.1.35, 9.0.99 or later
  2. Check conf/web.xml and app web.xml files for the DefaultServlet readonly init-param set to false; remove it unless you truly need WebDAV-style uploads
  3. If writes must stay on, upgrade and avoid file-based session persistence in the default location
  4. Migrate off EOL Tomcat 8.5 and older, which are known or suspected affected and get no fix
  5. Update container base images (e.g. official tomcat images) that bundle the runtime

How to check if you are affected or compromised

  • grep -R -A2 'readonly' conf/web.xml webapps/*/WEB-INF/web.xml to see if writes were enabled
  • Search access logs for PUT requests with Content-Range headers, followed by GET requests carrying an unusual JSESSIONID
  • Look for unexpected files in the work/Catalina/<host>/<app> session directory and for deserialization exceptions in catalina logs
  • Hunt for new JSP files in webapps that nobody deployed

What happened#

On March 10, 2025, the Apache Tomcat project disclosed CVE-2025-24813. The fixed releases, 11.0.3, 10.1.35 and 9.0.99, were already out; the 9.x security page lists 9.0.99 under its February 10 release. The bug was in how Tomcat handled partial PUT requests. According to the Tomcat security page, it wrote the upload to a temporary file whose name came from the user-supplied path, with path separators replaced by dots. That "internal dot" path equivalence lets an attacker place content where it should not go. The project rated it Important. The CVE record carries no numeric CNA score; CISA's ADP entry scores it CVSS 3.1 10.0. The bug was reported to Tomcat on January 13, 2025.

Exploitation came quickly. Wallarm reported a first attack on March 12, about 30 hours after disclosure. The technique uses a PUT to write a base64-encoded, ysoserial-generated serialized object into Tomcat's session store, then a GET with a matching JSESSIONID cookie to make Tomcat deserialize it. CISA added the CVE to KEV on April 1, 2025.

Who is affected#

Affected versions are Tomcat 11.0.0-M1 through 11.0.2, 10.1.0-M1 through 10.1.34, and 9.0.0.M1 through 9.0.98. EOL 8.5.0 through 8.5.100 is also known to be affected, and older EOL versions may be. Version alone does not make a server exploitable, though. Remote code execution requires all of the following:

  • Writes enabled on the default servlet. This is disabled by default.
  • Partial PUT support. This is enabled by default.
  • File-based session persistence in its default storage location.
  • A deserialization gadget library on the classpath.

The information disclosure and file injection variant needs writes enabled plus very specific upload layouts.

Do you really need to act?#

Most teams do not. The deciding precondition is readonly=false on the DefaultServlet, which almost nobody sets outside WebDAV-style upload setups. Rapid7 called the vulnerable configuration "relatively uncommon." It found only about 200 public open-source projects with write-enabled default servlets, most with fewer than 30 stars. Rapid7 also could not confirm any successful exploitation of real production environments and judged that reported "exploitation" was more likely failed attempts. Its advice was to patch without panicking.

Sources disagree on one point. Wallarm described file-based session storage as the default. Apache and Rapid7 say file-based persistence must be explicitly configured, and Rapid7 says it is disabled by default. Rapid7 also found that some of Apache's listed conditions for the disclosure variant were not strictly required. Both points change how likely exploitation is, not what you need to check.

Nineteen months on, the verdict is most-can-relax. Be on a fixed version, as any routine Tomcat update since February 2025 provides, and confirm the default servlet is read-only. If you find readonly=false on an old build, patch that server today.

What to do now#

  1. Check the version with $CATALINA_HOME/bin/version.sh and upgrade to 11.0.3, 10.1.35, 9.0.99 or later. Rebuild container images that bundle Tomcat.
  2. Run grep -R -A2 readonly conf/web.xml webapps/*/WEB-INF/web.xml. If a DefaultServlet has readonly set to false, remove it unless it is genuinely needed.
  3. If writes must stay on, avoid PersistentManager with a FileStore in the default location.
  4. Retire Tomcat 8.5 and older, which get no fix.

How to tell if you were hit#

Only servers with writes enabled could have been compromised, so check those first. Look in access logs for PUT requests with a Content-Range header, followed by GET requests with an odd JSESSIONID. Check the session directory under work/Catalina/ for files you did not expect, and check Tomcat logs for deserialization exceptions. Rapid7 published a Velociraptor artifact that hunts logs for these exceptions. Wallarm warns that follow-on activity could include uploaded JSP files or configuration changes, so compare webapps against your deployment artifacts.

Timeline#

  • — Issue reported to the Tomcat security team.
  • — Fixed releases begin shipping (9.0.99 listed under this date).
  • — Public disclosure; CVE published.
  • — Wallarm sees its first attack.
  • — Rapid7 assesses broad exploitation as unlikely.
  • — CISA adds CVE-2025-24813 to KEV.

Vulnerability records

  • CVE-2025-24813 · KEV 2025-04-01 · Path Equivalence: 'file.Name' (Internal Dot) leading to Remote Code Execution and/or Information disclosure and/or malicious content added to uploaded files…

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

  1. CVE Program — CVE-2025-24813 record (JSON) cveawg.mitre.org
  2. Apache Tomcat — Apache Tomcat 9.x vulnerabilities tomcat.apache.org
  3. Rapid7 — Apache Tomcat CVE-2025-24813: What You Need to Know rapid7.com
  4. Wallarm — One PUT Request to Own Tomcat: CVE-2025-24813 RCE is in the Wild lab.wallarm.com