PatchDayAlert
Field Note · 6 min read · 1,205 words By Colten Anderson

Patch Tomcat now, but the four-condition RCE probably isn't pointed at you

CVE-2025-24813 carries a 9.8 and a KEV listing, but real-world RCE needs four config conditions to all line up. Here's how to triage it against your actual deployment instead of the headline.

Patch Tomcat now, but the four-condition RCE probably isn't pointed at you

The patch is non-negotiable. The panic is optional, and for most shops it’s misplaced.

CVE-2025-24813 is a path-equivalence flaw in Apache Tomcat’s default servlet, disclosed March 10, 2025 and added to CISA’s KEV catalog on April 1 with a federal remediation deadline of April 22. NVD scores it 9.8 critical; CISA’s ADP scoring pushes it to 10.0. The fix is a point upgrade you should schedule regardless of anything else in this post. But the gap between “9.8 critical, actively exploited” and “your Tomcat is on fire” is wide, and knowing where your servers sit in that gap is what determines whether this jumps your maintenance window or rides the normal one.

What changed

Tomcat’s DefaultServlet built temp file names for partial PUT uploads by taking the user-supplied path and swapping the path separator for a dot. So WEB-INF/sensitive.xml became a temp file like WEB-INF.sensitive.xml. Two different request paths could resolve to the same file on disk, which collapses the boundary between a public uploads directory and a sibling sensitive one.

The full RCE chain, published by Wallarm and re-described by Zscaler ThreatLabz, is two requests. A PUT with a Content-Range header writes a base64-encoded serialized Java object into Tomcat’s session-store directory. A follow-up GET carries a JSESSIONID cookie pointing at that file, Tomcat’s file-based session manager deserializes the planted object, and if a gadget chain is on the classpath, that deserialization runs attacker code.

That two-stage design is the whole story. The file write is reachable under loose conditions. The RCE is the deserialization sink that the file write happens to reach, and reaching it needs four things true at once.

What it means for your environment

RCE requires all of these:

  • The default servlet is writable. Tomcat ships readonly=true. If you haven’t deliberately flipped it, you don’t have this.
  • Partial PUT is in play. The attack rides a Content-Range partial upload against that writable servlet.
  • File-based session persistence is on. PersistentManager with FileStore. This is not the default. In-memory sessions don’t reach the sink.
  • A deserialization gadget library is on the classpath. commons-collections and friends.

Miss any one and the RCE chain breaks. Rapid7 tested this in their March 19 ETR and called the vulnerable configuration “relatively uncommon,” with no confirmed successful exploitation against production environments. Recorded Future’s Insikt Group found no evidence of successful exploitation or named-actor activity against roughly 378,000 internet-exposed Tomcat instances on Shodan. None of the public sources break down how many of those 378k actually meet all four conditions. The honest answer is “small but non-zero,” and nobody has the precise number.

The looser risk is the one to take seriously. Path-traversal-style file read and write only needs the path-rewrite quirk plus a sub-directory relationship between your public and sensitive upload locations. No session store, no gadget chain. That’s the more likely real-world impact for a misconfigured server, and it’s why the patch matters even if you’re confident you don’t meet the RCE four.

Two version gotchas before you triage:

  • Your scanner may show the wrong severity. NVD originally published this at CVSS 5.5 on March 10, then re-scored to 9.8 on March 18 after the PoC dropped. A scanner that cached the record in that window still reads medium.
  • Embedded Tomcat counts. Anything bundling a vulnerable Tomcat is in scope, not just standalone installs. Red Hat mapped the CVE to JBoss Web Server and middleware; Jira admins were asking the same question in Atlassian’s community threads. Confirm the Tomcat version your vendor ships and read that vendor’s advisory. The app on top doesn’t insulate you.

What you need to do

Upgrade. The fixed releases, per Apache’s advisory:

  • 9.x: affected 9.0.0.M1 through 9.0.98, fixed in 9.0.99.
  • 10.1.x: affected 10.1.0-M1 through 10.1.34, fixed in 10.1.35.
  • 11.x: affected 11.0.0-M1 through 11.0.2, fixed in 11.0.3.
  • 8.5.x: NVD lists 8.5.0 through 8.5.100 as affected, but the branch is end-of-life as of October 2024 and won’t get a fix. The path off 8.5 is a major-version jump to a supported line, not a back-port. This is your riskiest cohort, because that upgrade historically lags and there’s no patch coming.

If you can’t move on a server immediately, the Apache advisory’s defense-in-depth steps buy you time, roughly easiest first:

  • Confirm readonly=true on the DefaultServlet. It’s the shipped default. Almost no production app needs PUT against the default servlet, since uploads route through the application’s own controllers. This single setting kills the bug for nearly every deployment.
  • Disable partial PUT if you genuinely need the servlet writable.
  • Don’t nest sensitive upload paths under public ones. That sub-directory relationship is what the information-disclosure variant exploits.
  • Move off PersistentManager + FileStore, or audit the classpath for gadget libraries. In-memory or Redis-backed sessions remove the RCE path entirely.

For retroactive hunting on a server you suspect was exposed, grep the access log for PUT requests carrying a Content-Range against the default servlet, correlated with a follow-up GET in the same session window. SonicWall shipped IPS signature 20839 on March 24, and Project Discovery’s Nuclei template exercises the file-write half non-destructively if you want to scan your own assets.

The window

The exploit traffic that earned the KEV listing is real but thin. GreyNoise tracked four unique attacking IPs as of March 20, growing to seven by April 1, and characterized all of it as “naive attackers utilizing PoC code.” “Active exploitation” here is the textbook definition, any observed attempt in the wild, not the colloquial one where your shop gets hit this week. Whether sophisticated abuse emerged after the public record went quiet in April isn’t visible in the sources.

So this is a scheduled-maintenance patch for most, with two exceptions that earn an expedited window: internet-facing servers you can’t immediately confirm are off the four-condition path, and anything still on EOL 8.5.

The durable lesson sits in the session store, not the PUT bug. As Rapid7 and the wider record show, the 9.8 score comes from the FileStore deserialization sink, not the upload flaw. Tomcat had this shape before, in CVE-2020-9484, and the fix here removes one upstream primitive without touching the sink. If you’re running PersistentManager with FileStore and a gadget chain on the classpath, every future “write any file anywhere” bug becomes RCE-shaped on first contact. Patching 24813 closes today’s door. Killing file-based sessions closes the hallway.

That’s the kind of distinction that decides whether a 9.8 is a Tuesday or a fire drill, and it’s what PatchDayAlert digs into on the CVEs that actually land in your queue.

Sources

Share

Related field notes

Get the free CVE triage cheat sheet

Subscribe and we'll email you the one-page triage flow for fresh CVEs. Plus the weekly digest.

Subscribe