CVE-2025-24813

What it actually does

The flaw is a path-equivalence weakness in Apache Tomcat’s handling of partial HTTP PUT requests through the Default Servlet. When the Default Servlet is configured to allow writes, an attacker can abuse Tomcat’s interpretation of paths containing internal dots and partial PUT behavior to read, overwrite, or append content to files that should not be reachable through the public upload path. In a higher-impact configuration, if Tomcat file-based session persistence is enabled in the default storage location and the application classpath contains a deserialization gadget, the attacker can place a crafted serialized session file and trigger deserialization, leading to remote code execution in the Tomcat process context. Affected Tomcat branches include 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, with downstream exposure in products bundling Tomcat or related Red Hat JBoss EAP components.

Why it matters to the business

Successful exploitation can expose sensitive uploaded files, corrupt or modify files used by applications, and in vulnerable configurations allow attackers to run code on internet-facing application servers. Because this issue is listed in CISA KEV, has active in-the-wild exploitation, and has a very high EPSS score, unpatched externally reachable Tomcat deployments should be treated as high-priority incident-risk systems. Operational consequences can include application compromise, web service disruption, data leakage, deployment of malware or web shells, lateral movement from the application tier, and emergency downtime for containment and recovery. The CISA remediation due date was 2025-04-22, so any remaining exposure is materially overdue.

How an attack unfolds

An attacker first identifies a Tomcat-hosted application where the Default Servlet is reachable and has write support enabled, typically by probing with HTTP PUT requests. The attacker then tests whether partial PUT is accepted by sending requests with Content-Range headers. For information disclosure or file tampering, the attacker targets upload paths where public and sensitive upload locations overlap and uses Tomcat’s path-equivalence behavior around filenames containing internal dots to read or inject content into sensitive files whose names are known or guessable. For remote code execution, the attacker looks for deployments using file-based session persistence in the default Tomcat work directory and an application dependency set that can be abused during Java deserialization. The attacker writes a crafted serialized session object using partial PUT, then sends a follow-up request with a matching JSESSIONID or session reference so Tomcat loads the file and deserializes attacker-controlled content. If successful, the payload executes with the permissions of the Tomcat process, after which the attacker may deploy a web shell, run operating-system commands, harvest credentials, or stage additional malware. Public reporting and KEV status indicate broad active exploitation rather than purely theoretical abuse.

How to fix it

Upgrade Apache Tomcat to a fixed release for the deployed branch: Tomcat 11.0.3 or later, Tomcat 10.1.35 or later, and the fixed 9.0.x vendor release identified for the environment; the provided advisory text names 9.0.98, but operators should verify against the current Apache Tomcat advisory for the 9.0 branch because affected-version and fixed-version notation may vary by source. For source builds, include the Apache Tomcat fix at commit 7145107845fe82dafee783bb0bfd6bea028e173b or a later trusted upstream revision. For Red Hat JBoss EAP 7.3 on EL7, apply vendor packages at or above the listed fixed builds, including eap7-undertow 0:2.0.41-1.SP1_redhat_00001.1.el7eap, eap7-apache-cxf and related CXF packages 0:3.3.12-1.redhat_00001.1.el7eap, eap7-ironjacamar packages 0:1.5.3-1.Final_redhat_00001.1.el7eap, eap7-jakarta-el 0:3.0.3-3.redhat_00007.1.el7eap, eap7-jboss-ejb-client 0:4.0.43-1.Final_redhat_00001.1.el7eap, and eap7-jboss-server-migration packages 0:1.7.2-10.Final_redhat_00011.1.el7eap. As immediate mitigations, disable write access on the Default Servlet by ensuring it remains read-only, disable partial PUT support where not required, restrict or remove HTTP PUT from public routes at the reverse proxy or WAF, avoid overlapping public and sensitive upload directories, move session persistence away from the default file-based location or disable file-based session persistence if unnecessary, and remove unsafe deserialization gadget libraries where possible. If exploitation is suspected, rebuild affected application servers from trusted images after preserving forensic evidence, rotate secrets accessible to the application, and redeploy clean application artifacts.

How to confirm the fix worked

Confirm the running Tomcat version and packaged downstream component versions from server startup logs, package managers, container image manifests, and application server management interfaces. Verify that the Default Servlet is not writable by inspecting web.xml and application-specific servlet configuration for readonly=false or equivalent settings. Test exposure from an untrusted network segment by sending a benign HTTP PUT to a non-production-safe test path and confirming that the server rejects it with 403, 405, or equivalent policy denial rather than creating or modifying content. Test that partial PUT requests using Content-Range are rejected or blocked when not explicitly required. Review Tomcat configuration for PersistentManager and FileStore usage, especially file-based session storage under the default work directory. Validate that public upload directories are not parents of sensitive upload paths and that sensitive files are stored outside web-served directories. After patching, confirm the active process has restarted and is no longer running vulnerable libraries from an old exploded WAR, container layer, or application server home.

Typical attack path

1. Scan internet-facing services for Apache Tomcat or applications returning Tomcat-specific headers, error pages, cookies, or URL patterns.
2. Identify potentially vulnerable versions or downstream products that bundle affected Tomcat components.
3. Probe the Default Servlet with HTTP PUT requests to determine whether write operations are enabled.
4. Send partial PUT requests using Content-Range headers and paths containing internal-dot filename patterns to test path-equivalence behavior.
5. For file disclosure or tampering, target known or guessable upload filenames in overlapping public and sensitive upload directories.
6. For remote code execution, write a crafted serialized session payload into Tomcat’s file-based session storage location.
7. Trigger session loading by requesting the application with a chosen JSESSIONID or related session identifier.
8. Execute commands or load malicious classes through a deserialization gadget available in the application classpath.
9. Establish persistence, commonly through a web shell, modified application artifact, scheduled task, or secondary malware.
10. Clean up obvious request artifacts or continue using the compromised application server for lateral movement and data access.

How to detect it

Review HTTP access logs, reverse proxy logs, WAF logs, EDR telemetry, file integrity monitoring, Tomcat application logs, and operating-system audit logs for evidence of exploitation. High-signal web patterns include HTTP PUT requests to Tomcat-hosted applications, PUT requests with Content-Range headers, requests targeting upload directories with filenames containing unexpected internal dots, and a sequence where a PUT is followed by a request carrying a matching or unusual JSESSIONID value. Check Tomcat logs for Default Servlet write activity, unexpected 201 or 204 responses to PUT, deserialization errors, class-loading errors, or session persistence errors around the same timestamp. On disk, inspect CATALINA_BASE/work/Catalina/localhost and application upload directories for recently created or modified .session, .ser, .jsp, .jspx, .war, .class, or suspicious binary files owned by the Tomcat user. Compare file modification times against access-log PUT timestamps. Look for child processes spawned by the Tomcat Java process, such as shells, command interpreters, download utilities, scripting runtimes, or archive tools. Because exploitation is publicly reported in active campaigns, broaden hunting to include post-exploitation behavior such as web shell access, outbound connections from the application server, credential file reads, and deployment of unfamiliar persistence mechanisms.

• "PUT "
• "Content-Range:"
• " 201 " "PUT "
• " 204 " "PUT "
• "JSESSIONID="
• "readonly=\"false\""
• "<param-name>readonly</param-name>"
• "<param-value>false</param-value>"
• "org.apache.catalina.servlets.DefaultServlet"
• "org.apache.catalina.session.PersistentManager"
• "org.apache.catalina.session.FileStore"
• "work/Catalina/localhost"
• ".session"
• ".ser"
• ".jspx"
• ".jsp"
• "java.io.InvalidClassException"
• "java.io.StreamCorruptedException"
• "java.io.ObjectInputStream"
• "Cannot deserialize session"
• "deserialization"
• "/bin/sh"
• "/bin/bash"
• "cmd.exe"
• "powershell.exe"
• "curl "
• "wget "

What your security team should do

• Immediately inventory internet-facing Tomcat and Tomcat-derived application servers, including container images, embedded Tomcat applications, and Red Hat JBoss EAP deployments.
• Prioritize patching or isolation of externally reachable systems because the vulnerability is in CISA KEV, actively exploited, and has very high exploitation probability.
• Block or tightly restrict HTTP PUT and requests containing Content-Range at edge controls unless explicitly required by the application.
• Audit Tomcat Default Servlet configuration for writable mode and revert to read-only wherever possible.
• Search historical web access logs for PUT requests, partial PUT Content-Range headers, suspicious JSESSIONID values, and unexpected writes to upload or Tomcat work directories.
• Hunt for unexpected serialized session files, modified uploaded content, JSP/web shell files, and new executable artifacts created by the Tomcat process.
• If indicators of exploitation are present, treat the host as potentially compromised: preserve evidence, isolate it, rotate credentials, and rebuild from known-good media.
• Add WAF/SIEM detections for HTTP PUT plus Content-Range, unusual internal-dot upload paths, and session-trigger requests following PUT activity from the same source.
• Review application dependencies for known Java deserialization gadget chains and remove unnecessary high-risk libraries.
• Track vendor advisories for downstream products bundling Tomcat and apply exact package-level fixed versions rather than relying only on the top-level application name.