TL;DR
- CVE-2025-24813 is a remote code execution vulnerability in Apache Tomcat that attackers began exploiting in the wild just 30 hours after a proof-of-concept appeared on GitHub [2].
- It affects 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 — patched versions are 9.0.99, 10.1.35, and 11.0.3 [1].
- Exploitation chains a partial PUT upload with Java deserialization of session data, meaning attackers can run arbitrary code on vulnerable servers [3].
- Patching is straightforward, and most organisations can verify their exposure and apply fixes within a single maintenance window.
What Is CVE-2025-24813 and Why Does It Matter?
Millions of organisations rely on Apache Tomcat to power Java-based web applications — from banking portals to e-commerce checkouts [5]. CVE-2025-24813, disclosed by the Apache Software Foundation in March 2025, allows an unauthenticated attacker to execute arbitrary code on a Tomcat server [1]. CISA added it to the Known Exploited Vulnerabilities catalog given confirmed in-the-wild activity [3][4].
Free Resource
Get Our Weekly Cybersecurity Digest
Every Thursday: the threats that matter, what they mean for your business, and exactly what to do. Trusted by SMB owners across Australia.
No spam. No tracking. Unsubscribe anytime. Privacy
Weekly Threat Briefing — Free
Curated threat intelligence for Australian SMBs. Active campaigns, new CVEs, and practical mitigations — every week, straight to your inbox.
Subscribe Free →What makes this one notable is speed. Wallarm documented active exploitation just 30 hours after a proof-of-concept appeared on GitHub [2] — reinforcing the Verizon DBIR trend that the disclosure-to-exploitation window keeps shrinking [9].
How Does the Exploit Actually Work?
The attack is a two-step process:
Step 1 — Upload. The attacker sends a partial PUT request containing a malicious serialised Java object disguised as a session file. Partial PUT is enabled by default in affected versions [1][10].
Step 2 — Trigger. A follow-up request causes Tomcat to load and deserialise that session file. If the server uses file-based session persistence at the default path, it executes the attacker's code [8].
Conditions required for exploitation:
- The default servlet allows writes (not the out-of-the-box default, but common in development or file-upload scenarios).
- Partial PUT support is enabled (this is the default).
- File-based session persistence uses the default storage location.
- A deserialization-vulnerable library is present in the classpath.
Not every Tomcat instance meets all four conditions, but each is common enough in real-world deployments that the risk is meaningful [10].
Which Versions Are Affected and What Should You Upgrade To?
The affected version ranges and their fixes are clear-cut [1]:
| Branch | Affected Range | Fixed Version |
|---|---|---|
| Tomcat 9 | 9.0.0-M1 – 9.0.98 | 9.0.99 |
| Tomcat 10 | 10.1.0-M1 – 10.1.34 | 10.1.35 |
| Tomcat 11 | 11.0.0-M1 – 11.0.2 | 11.0.3 |
Upgrading is a standard point-release — no major API changes or breaking modifications [1].
ISO 27001 SMB Starter Pack — $97
Threat intelligence is one thing — having the policies and controls to respond is another. Get the complete ISO 27001 starter kit for SMBs.
Get the Starter Pack →How Can You Check If Your Organisation Is Exposed?
- Asset discovery. Identify every Tomcat instance — tools like Shodan can reveal forgotten internet-facing instances [5].
- Version audit. Confirm each instance's version via
/manager/statusorversion.shin the Tomcatbindirectory. - Configuration review. Check whether the default servlet allows writes, and whether file-based session persistence is active at the default path.
- Library inventory. Review your classpath for deserialization-vulnerable libraries (e.g., older Apache Commons Collections) [7].
- Patch. Test in staging, then roll to production. Organisations with mature patching programmes resolve incidents 80% faster [6].
What If You Can't Patch Immediately?
Sometimes maintenance windows are weeks away. In the interim, consider these mitigations:
- Disable partial PUT if your applications don't require it. This breaks the upload step of the exploit chain.
- Set the default servlet to read-only (
readonly="true"inweb.xml). This is the default setting — if someone changed it, change it back. - Switch session persistence from file-based to JDBC-based or disable persistence entirely if it's not needed.
- Remove or update vulnerable deserialization libraries in your application's classpath.
Each mitigation removes one link in the exploit chain. Remove any single link and the attack fails. That said, patching remains the gold standard — mitigations are a bridge, not a destination [7].
What's the Bigger Takeaway for Business Leaders?
This vulnerability is a reminder, not an alarm. The disclosure → PoC → exploitation pattern is the normal rhythm of modern software, and timely patching remains one of the most cost-effective security investments [9]. The 30-hour exploitation window reinforces what security teams already know: automated patch pipelines, accurate asset inventories, and configuration baselines pay for themselves many times over [6][9].
FAQ
Yes. Wallarm confirmed exploitation within 30 hours of a PoC appearing on GitHub [2], and CISA added it to the Known Exploited Vulnerabilities catalog [4].
Every server running an affected version should be upgraded. Even if your configuration doesn't meet all four exploitation conditions today, configurations change. Patching removes the risk entirely [1].
It requires four conditions to align (partial PUT, writable servlet, file-based sessions, vulnerable library) [10]. Not single-click, but common enough in real deployments to be meaningful.
IBM's 2025 report places the average breach cost at USD $4.88 million [6]. Patching costs minutes of planned downtime by comparison.
Versions 9.0.99, 10.1.35, and 11.0.3 are available on the official Apache Tomcat download page [1].
References
[1] Apache Software Foundation, "CVE-2025-24813: Apache Tomcat - Potential RCE and/or Information disclosure," Apache Tomcat Security, Mar. 2025.
[2] Wallarm, "CVE-2025-24813: Apache Tomcat RCE Exploited in the Wild," Wallarm Research, Mar. 2026.
[3] NIST National Vulnerability Database, "CVE-2025-24813 Detail," NVD, 2025.
[4] CISA, "Known Exploited Vulnerabilities Catalog," CISA.gov, 2026.
[5] Shodan, "Apache Tomcat Server Distribution," Shodan.io, 2026.
[6] IBM Security, "Cost of a Data Breach Report 2025," IBM, 2025.
[7] ASD Australian Signals Directorate, "Essential Eight Maturity Model," Australian Government, 2025.
[8] OWASP, "Deserialization of Untrusted Data," OWASP Top 10, 2021.
[9] Verizon, "Data Breach Investigations Report 2025," Verizon, 2025.
[10] SecurityWeek, "Apache Tomcat Vulnerability Important to Patch, Difficult to Exploit," SecurityWeek, Mar. 2026.
Your Tomcat fleet deserves the same attention as any other critical infrastructure. If you'd like a hand building a patch pipeline or reviewing your web server configurations, let's talk.
Work With Us
Ready to strengthen your security posture?
lilMONSTER assesses your risks, builds the tools, and stays with you after the engagement ends. No clipboard-and-leave consulting.
Book a Free Consultation →TL;DR
- A bug in Apache Tomcat (a program that runs websites) lets attackers take control of a server.
- Attackers started using it just 30 hours after someone showed how it works online.
- There's a fix — just update to the newest version of Tomcat.
What Happened, in Plain English?
Imagine your school has lockers. Now imagine someone figured out that sliding a specially shaped package through the air vent makes the locker open itself and follow whatever instructions are inside — even "give me everyone's lunch money."
That's basically what happened with Apache Tomcat, a program millions of companies use to run websites [5]. A bug called CVE-2025-24813 lets an attacker send a sneaky file to the server [1]. When the server opens it, it follows the hidden instructions, giving the attacker control [8].
The scary part: someone posted a how-to guide online, and within 30 hours, real attackers were already using it [2].
Which Versions Are Affected?
Three "flavours" of Tomcat have this bug [1]:
- Tomcat 9: versions 9.0.0-M1 through 9.0.98 → update to 9.0.99
- Tomcat 10: versions 10.1.0-M1 through 10.1.34 → update to 10.1.35
- Tomcat 11: versions 11.0.0-M1 through 11.0.2 → update to 11.0.3
What Should You Do?
- Find your Tomcat servers. Check which version each one is running.
- Update them. Install the patched version (9.0.99, 10.1.35, or 11.0.3) [1].
- Check your settings. Make sure the server doesn't let unknown visitors upload files [10].
- Clean up old libraries. Remove or update outdated Java libraries that are known to be unsafe [7][8].
FAQ
Yes. Tomcat often runs behind the scenes in tools you might not realise depend on it [5].
No — it's a small point-release designed to change as little as possible. Test in staging first, then roll it out [1].
Serious enough that CISA flagged it [4], but completely fixable with a straightforward update. The fix costs minutes; ignoring it could cost millions [6][9].
References
[1] Apache Software Foundation, "CVE-2025-24813: Apache Tomcat - Potential RCE and/or Information disclosure," Apache Tomcat Security, Mar. 2025.
[2] Wallarm, "CVE-2025-24813: Apache Tomcat RCE Exploited in the Wild," Wallarm Research, Mar. 2026.
[3] NIST National Vulnerability Database, "CVE-2025-24813 Detail," NVD, 2025.
[4] CISA, "Known Exploited Vulnerabilities Catalog," CISA.gov, 2026.
[5] Shodan, "Apache Tomcat Server Distribution," Shodan.io, 2026.
[6] IBM Security, "Cost of a Data Breach Report 2025," IBM, 2025.
[7] ASD Australian Signals Directorate, "Essential Eight Maturity Model," Australian Government, 2025.
[8] OWASP, "Deserialization of Untrusted Data," OWASP Top 10, 2021.
[9] Verizon, "Data Breach Investigations Report 2025," Verizon, 2025.
[10] SecurityWeek, "Apache Tomcat Vulnerability Important to Patch, Difficult to Exploit," SecurityWeek, Mar. 2026.
Want help checking your servers or setting up automatic updates? We can walk you through it.
