Apache Tomcat CVE-2025-24813

Go straight to an AI summary of this blog post instead

Key Takeaways:

CVE-2025-24813 can allow unauthenticated attackers to achieve remote code execution, information disclosure, or content injection on Tomcat servers – but only when the default servlet has writes enabled (off by default) and a few other non-default conditions are met.
Affected teams should inventory Tomcat deployments, confirm whether security constraints are in use, and upgrade to patched versions as soon as possible.
Older or hard-to-upgrade Tomcat environments need a clear risk-reduction plan instead of relying on unpatched, end-of-life versions.

If you’re managing Apache Tomcat instances in production, CVE-2025-24813 is one of those vulnerabilities that demands your immediate attention. Not because it’s flashy or generating headlines, but because it represents a real, exploitable risk in configurations that are surprisingly common.

This isn’t a theoretical corner case that only affects someone running Tomcat on a Raspberry Pi in debug mode. We’re talking about a vulnerability that can affect real production environments, potentially giving attackers a foothold in your application infrastructure. Let’s break down what CVE-2025-24813 actually is, who needs to worry about it, and how to address it without turning your week into a crisis.

What Is CVE-2025-24813?

CVE-2025-24813 is a path equivalence vulnerability in Apache Tomcat that can lead to unauthenticated remote code execution, information disclosure, or content injection in uploaded files. In practical terms, an attacker who can reach a vulnerable Tomcat instance may be able to upload a malicious file and trick Tomcat into executing it – no credentials required.

The vulnerability stems from how Tomcat’s partial PUT handling constructs temporary file paths. The original implementation generated a temporary filename based on the user-provided file name and path, with the path separator replaced by a dot. Combined with Tomcat’s file-based session persistence, this design lets an attacker upload a crafted Java serialized payload to the session directory and then trigger deserialization with a follow-up GET request carrying a matching JSESSIONID cookie. The result is remote code execution.

What makes this particularly concerning is that no authentication is required, and the payload can be Base64-encoded to evade common detection rules. Once an attacker understands the file-path collision and the deserialization trigger, exploitation is mechanical.

That said, the vulnerability has real prerequisites. Exploitation requires all of the following to be true: writes are enabled on the default servlet (off by default – the readonly parameter in conf/web.xml has to be flipped to false), Tomcat is configured to use file-based session persistence (not the default), and the application’s classpath includes a deserialization gadget chain the attacker can leverage. Apache initially rated the CVE as Important rather than Critical for exactly this reason. But where the prerequisites do line up, the impact is full server compromise – and CISA added it to the Known Exploited Vulnerabilities catalog within weeks of disclosure. –

Which Tomcat Versions Are Affected?

CVE-2025-24813 affects multiple branches of Apache Tomcat, though the exact vulnerable version ranges depend on which major version you’re running. Here’s the breakdown:

Apache Tomcat 11.0.x is vulnerable in versions 11.0.0-M1 through 11.0.2. The fix landed in 11.0.3, so you need to be on 11.0.3 or later to be patched.
Apache Tomcat 10.1.x is vulnerable in 10.1.0-M1 through 10.1.34. The fix is included in 10.1.35 and subsequent releases.
Apache Tomcat 9.0.x is vulnerable in 9.0.0.M1 through 9.0.98. You need version 9.0.99 or later to address the vulnerability.
Apache Tomcat 8.5.x reached end of life on 31 March 2024, before this CVE was disclosed. The Apache Tomcat project did not issue a community patch for 8.5, so any 8.5.x deployment is permanently exposed unless you migrate to a supported branch or get coverage through a commercial extended-support provider.

Notably, Tomcat 8.5 and anything older – the 8.0.x and 7.0.x branches – have all reached end of life and won’t receive a community patch for CVE-2025-24813. If you’re on any of these branches, your only options are migrating to a supported version or getting coverage through a commercial extended-support provider. We’ll talk about both in a bit.

The key thing to understand is that this isn’t just affecting bleeding-edge versions or obscure configurations. The vulnerability spans the major Tomcat versions that are actively deployed in production right now, including the well-established 9.0 and 8.5 branches that power countless enterprise applications.

Understanding the Exploitation Scenario

To truly grasp the risk, you need to understand when and how this vulnerability actually matters in production environments.

The exploitation scenario for CVE-2025-24813 revolves around Tomcat’s default servlet – the component that handles direct file requests – and a feature called partial PUT, which lets clients upload pieces of a file across multiple requests. By default, the default servlet is read-only and ignores PUT requests entirely, which is why most installations are not exposed. The vulnerability becomes reachable only when an administrator has explicitly set the readonly parameter to false in conf/web.xml, opting in to uploads via the default servlet.

Here’s where it gets interesting: even with writes enabled, exploitation requires additional ingredients. Tomcat has to be configured for file-based session persistence (the FileStore manager rather than in-memory sessions), the application’s classpath has to include a deserialization gadget chain, and the attacker needs to be able to reach the upload endpoint over the network.

When those conditions line up, the attack chain is short. The attacker sends a partial PUT request that uploads a serialized Java payload to a path they control. Because Tomcat’s partial PUT implementation translates the request URI into a temporary filename – replacing path separators with dots – the uploaded file lands exactly where Tomcat will later look for session data. A follow-up GET request with a crafted JSESSIONID cookie causes Tomcat to deserialize the file, execute the gadget chain, and hand the attacker remote code execution. No authentication is required at any step.

In practical terms, this isn’t “an attacker can see one extra endpoint.” It’s “an attacker uploads a payload, sends one more request, and runs code as the Tomcat process.”

If your application doesn’t enable writes on the default servlet, or doesn’t use file-based session persistence, you are not exposed to the remote code execution path of this CVE. You may still be exposed to the information disclosure or content injection variants under slightly different conditions, so patching is still the right call – but the urgency depends entirely on your configuration.

Assessing Your Exposure

Before you start patching, it’s worth taking a moment to understand whether your specific Tomcat deployments are actually at risk from CVE-2025-24813.

First, check your Tomcat versions. This sounds obvious, but in complex environments with multiple Tomcat instances, you’d be surprised how often teams don’t have a complete inventory. If you’re running anything older than the patched versions listed earlier, you’re potentially vulnerable. Don’t forget about those Tomcat instances running in Docker containers, hidden in microservice deployments, or embedded in other applications.
Second, review your security constraint configurations. Look at the ‘web.xml’ files (and any programmatic security configurations) for your deployed applications. Are you using ‘<security-constraint>’ elements to protect resources? Are you relying on Tomcat’s built-in authentication mechanisms? If the answer is yes, you need to treat this vulnerability seriously.
Third, consider your deployment architecture. Are your Tomcat instances exposed directly to the internet, or are they behind reverse proxies, API gateways, or other security layers? While defense in depth is always good, don’t assume that a WAF or reverse proxy automatically protects you from this vulnerability. The request manipulation needed to exploit CVE-2025-24813 might pass through those layers just fine.
Finally, think about what you’re protecting. Even if you’re technically vulnerable, the actual risk depends on what an attacker could access by bypassing your security constraints. If we’re talking about an admin interface with access to customer data or system controls, that’s high-stakes. If it’s an internal monitoring endpoint that only shows sanitized metrics, the urgency is different.

The goal here isn’t to downplay the vulnerability or talk yourself out of patching. It’s to understand your risk profile so you can prioritize remediation efforts appropriately, especially if you’re managing dozens or hundreds of Tomcat instances.

Mitigation and Patching Steps

The primary and recommended fix for CVE-2025-24813 is straightforward: upgrade to a patched version of Apache Tomcat. But as anyone who’s managed production Tomcat deployments knows, “just upgrade” is easier said than done.

The Clean Upgrade Path

If you can upgrade cleanly, here’s what that looks like:

Identify your current Tomcat version across all deployments. Use catalina.sh version or check the version number in your Tomcat installation directory. Don’t rely on documentation or runbooks that might be outdated.
Download the appropriate patched version from the official Apache Tomcat website. For Tomcat 11, get 11.0.3 or later. For 10.1, get 10.1.35 or later. For 9.0, get 9.0.99 or later. If you’re still on Tomcat 8.5, there is no community patch – see “When Upgrading Isn’t Immediately Feasible” below. Always download from official sources, never from random mirrors or third-party repositories.
Test the upgrade in a non-production environment first. This isn’t optional paranoia – it’s basic operational hygiene. Tomcat upgrades occasionally introduce behavioral changes or performance characteristics that can surprise you. Validate that your applications still work, that performance metrics look reasonable, and that any monitoring or logging integrations still function.
Plan your production rollout. Consider your deployment windows, traffic patterns, and rollback procedures. If you’re running Tomcat behind a load balancer, you can upgrade instances one at a time. If you’re in a more constrained environment, you might need a maintenance window. Make sure you’ve got a tested rollback plan in case something goes sideways.
Apply the upgrade and verify that you’re running the patched version. Don’t just assume the upgrade worked – actually check the version number post-deployment.

Configuration-Based Mitigations

While upgrading is the proper fix, there might be configuration changes that can reduce your exposure in the short term. Review your security constraints to ensure they’re as specific and restrictive as possible. Overly broad URL patterns or loosely defined constraints can increase your attack surface.

Consider implementing additional authentication layers at the reverse proxy or API gateway level if you have those components in your architecture. Again, this isn’t a substitute for patching, but it adds defense in depth.

If you’re running Tomcat instances that host multiple web applications, audit which apps are deployed and whether they all need to be there. Reducing the number of deployed applications reduces the potential attack surface.

Operational Considerations

Here are some practical things to watch out for during the patching process:

Restart requirements. Upgrading Tomcat requires a restart. That means downtime for your applications unless you’ve architected for zero-downtime deployments. Plan accordingly.
Configuration file compatibility. Most Tomcat upgrades are backward-compatible with existing configuration files, but not always. Pay particular attention to any customizations you’ve made to server.xml, web.xml, or other configuration files.
JVM version dependencies. Different Tomcat versions have different Java version requirements. Tomcat 10.1 requires Java 11. Tomcat 11 requires Java 17 or later. If you’re upgrading from an older Tomcat version, you might need to upgrade your JVM as well, which adds complexity.
Library and connector compatibility. If you’re using JDBC drivers, JMS connectors, or other libraries with Tomcat, verify they’re compatible with the version you’re upgrading to. This is particularly important for older enterprise applications.
Monitoring and APM agents. If you’re running monitoring agents or APM tools that hook into Tomcat, verify they still work after the upgrade. Some agents are sensitive to Tomcat version changes.

When Upgrading Isn’t Immediately Feasible

Let’s be realistic: not every organization can drop everything and upgrade Tomcat instances across the board the moment a CVE drops. Sometimes you’re dealing with vendor-provided applications that bundle specific Tomcat versions and don’t support newer ones. Sometimes you’re running legacy applications on older Tomcat branches that would require significant testing and validation to upgrade. Sometimes you’re just resource-constrained and need to prioritize the most critical instances first.

For teams running older Tomcat versions that can’t be upgraded immediately, extended security support options exist to help bridge the gap. Services like TuxCare’s Endless Lifecycle Support (ELS) provide continued security patches for end-of-life software versions, including older Tomcat releases that no longer receive updates from the Apache project.

This isn’t a substitute for proper patching and upgrading to current versions. It’s a pragmatic risk-reduction option that can be part of a phased remediation plan. If you’re running Tomcat 8.0 or 7.0 instances that can’t be migrated immediately, extended support can keep those systems protected from known vulnerabilities while you work through the upgrade process on a realistic timeline.

The key is being deliberate about it. If you’re using extended support, have a clear plan for eventually moving to current Tomcat versions. Don’t let extended support become an excuse to defer technical debt indefinitely.

Beyond This CVE: Building Resilient Tomcat Deployments

CVE-2025-24813 is one vulnerability, but it’s part of a larger pattern. Tomcat vulnerabilities are discovered regularly, and they always will be. The question isn’t whether you’ll need to patch Tomcat again – it’s how quickly and smoothly you can do it when the next CVE drops.

This means building operational practices that support rapid patching: maintaining clear inventories of all Tomcat deployments, having tested upgrade procedures, running regular vulnerability scans, and keeping staging environments that mirror production for testing updates.

It also means making architectural choices that support security: running Tomcat instances behind reverse proxies, implementing network segmentation, using container orchestration that makes rolling updates easier, and following the principle of least privilege for Tomcat process permissions.

And it means staying informed. Subscribe to the Apache Tomcat security mailing list. Monitor CVE databases for Tomcat-related vulnerabilities. Don’t wait for a vulnerability to become public knowledge before you start planning how to respond.

Taking Action

CVE-2025-24813 is serious, but it’s also addressable. The patches exist, the mitigation steps are clear, and the exploitation requirements are specific enough that you can make informed decisions about prioritization.

If you’re running affected Tomcat versions and using security constraints to protect resources, treat this as a high-priority patching task. Test the upgrade, plan your rollout, and get those instances updated. If you’re running older Tomcat versions that won’t receive patches, evaluate your options for extended support or accelerate your migration plans.

The worst response to CVE-2025-24813 is to ignore it and hope it doesn’t matter. The best response is to understand your exposure, prioritize your remediation efforts, and execute your patches systematically.

Your Tomcat instances are part of your application infrastructure. Keeping them secure isn’t optional work that happens when you have spare time. It’s a core operational responsibility that deserves time, attention, and resources.

Summary