Apache Tomcat 11.0.3 - Remote Code Execution

Apache Tomcat 11.0.3 - Path Equivalence Remote Code Execution (CVE-2025-24813)

Summary: CVE-2025-24813 is a high-severity vulnerability in Apache Tomcat where a path-equivalence issue combined with unsafe Java deserialization of session data can lead to remote code execution (RCE). It affects a range of Tomcat branches and has been assigned a CVSS score reflecting a critical impact for unpatched systems.

Key facts

• CVE: CVE-2025-24813
• Affected versions (examples): Tomcat releases prior to 11.0.3, 10.1.35 and 9.0.98 (refer to vendor advisories for exact lists)
• Impact: Remote Code Execution via unsafe deserialization of session data (high severity)
• CWE: CWE-502 (Deserialization of Untrusted Data) and CWE-44 (Improper Pathname Manipulation)
• References: vendor advisories and independent analyses (see vendor site and third‑party writeups)

What the vulnerability is — high level

This vulnerability results from two interacting issues:

• A path-equivalence or request-routing behavior that allows specially crafted requests to cause the server to read session-like data from locations or names not originally intended by the application.
• Tomcat’s handling of serialized Java session data: when the application (or container) deserializes data that can be controlled by an attacker, a malicious gadget chain can lead to arbitrary code execution on the JVM.

Combined, these allow a remote unauthenticated attacker to cause the server to deserialize attacker-controlled serialized objects (or other session content) and thereby achieve RCE in vulnerable configurations.

Why this is critical

• Deserialization vulnerabilities in Java can lead directly to arbitrary code execution if exploitable gadget classes are present on the classpath.
• Tomcat is widely deployed in internet-facing environments and often runs web applications with elevated privileges.
• An attacker who successfully exploits this can execute commands, deploy persistent backdoors, steal data, or pivot within a network.

Safe detection and hunting (for defenders)

When investigating potentially vulnerable or exploited systems, focus on local checks, log evidence and file-system artifacts. Below are non-exploitative, defensive checks you can perform on hosts you manage.

1) Check Tomcat version locally

# Example: check RELEASE-NOTES or catalina.jar manifest (local host)
grep -i "Apache Tomcat" /opt/tomcat/RELEASE-NOTES 2>/dev/null || \
unzip -p /opt/tomcat/lib/catalina.jar META-INF/MANIFEST.MF | grep Implementation-Version

Explanation: This snippet shows safe, local methods to determine the Tomcat release installed. Replace /opt/tomcat with your installation path. Do not use remote fingerprinting without authorization.

2) Look for unexpected session files or newly created files

# Example: search for session files under the Tomcat work or webapps directories
find /opt/tomcat -type f -name "*session*" -printf "%p %TY-%Tm-%Td %TT\n"

Explanation: Attackers attempting to abuse session deserialization may create or influence files that Tomcat later loads as session state. Investigate unexpected files, recent timestamp changes, or unfamiliar ownership.

3) Hunt for suspicious request patterns in access logs

# Example: search access logs for unusual HTTP methods, unexpected PUT/DELETE to app paths, or requests with unusual cookies
grep -E "PUT|DELETE|TRACE" /opt/tomcat/logs/*access*.log
grep -E "JSESSIONID=.*\." /opt/tomcat/logs/*access*.log

Explanation: While not definitive, abnormal HTTP methods or unusual cookie values (for example, cookie values that look crafted) warrant further review in a controlled, authorized investigation.

Mitigation and hardening (recommended immediate steps)

When facing a critical remote code execution vulnerability, prioritize the vendor-recommended patches first. While you plan and apply updates, apply compensating controls to reduce risk.

1) Patch or upgrade (primary remediation)

• Apply the official Tomcat updates from the vendor to a fixed release (for example, versions at or above the fixed tags published by Apache for the relevant branch).
• Test upgrades in staging before rolling into production, but treat patching as the highest priority for exposed systems.

2) Disable unnecessary HTTP methods and restrict uploads

Limit or disable HTTP methods you do not need (PUT, DELETE) at the web server or WAF level and restrict file upload endpoints with strong authentication and allowlisting.

3) Disable file-based session persistence (if not required)

Explanation: Removing a persistent session pathname prevents Tomcat from writing/reading sessions to disk between restarts. This is a defensive measure; validate application behavior because some apps expect session persistence.

4) Apply Java deserialization filters (jdk.serialFilter)

# Example JAVA_OPTS to set a serialization filter (tailor to your application)
export CATALINA_OPTS="$CATALINA_OPTS -Djdk.serialFilter=com.mycompany.safepkg.*;java.lang.String;java.util.HashMap;!*"

Explanation: The Java Platform Serialization Filtering mechanism (jdk.serialFilter) lets you declare allowed/denied patterns for deserialized classes. The example allows a small set of packages/classes and then denies everything else. Filters must be tested — an overly strict filter can break legitimate deserialization.

5) Strengthen network egress controls and privilege separation

• Restrict outbound network connectivity from application hosts to reduce the ability of an attacker to phone home (DNS, HTTP).
• Run Tomcat as a least-privilege user, isolate with containers or VMs, and enforce OS-level confinement (SELinux, AppArmor).

6) WAF and detection rules (example defensive rule)

# Example ModSecurity rule to detect a Java serialization magic header in request bodies (defensive)
SecRule REQUEST_METHOD "^(POST|PUT)$" \
  "chain,phase:2,deny,log,msg:'Possible Java serialized object in request body'"
SecRule REQUEST_BODY|ARGS "@rx \xAC\xED\x00\x05" \
  "t:none"

Explanation: Java serialized objects start with a well-known magic header (0xAC 0xED 0x00 0x05). A WAF rule can flag binary POST/PUT bodies containing that header. Use such rules to detect/block suspicious requests, but tune to avoid false positives from legitimate binary traffic.

Incident response guidance

• If you suspect exploitation: isolate the affected host(s) from networks, preserve logs and disk images, and capture memory if permitted by your process.
• Collect Tomcat access and error logs, OS logs, and any newly created files or processes for forensic analysis.
• Rotate secrets, application credentials and any x.509 certs or API keys that may have been exposed or used on compromised hosts.
• Reinstall from known-good images after root cause analysis, and patch prior to reconnecting to production networks.
• Report incidents to relevant stakeholders and legal/incident response teams as required by policy.

Long-term recommendations and secure development practices

• Avoid Java serialization for untrusted input; prefer safer data formats (JSON, protobufs with explicit schemas, etc.).
• Harden the application server configuration: disable unused services, apply strict authentication/authorization to management apps (Manager/HostManager), and use strong audit logging.
• Implement allowlisting for deserialization or use proven libraries that provide safe deserialization primitives.
• Perform periodic dependency and configuration audits, vulnerability scanning, and regular patching cycles.

Example: checklist for administrators (prioritized)

• Verify if your Tomcat installations are running versions affected by CVE-2025-24813.
• Apply vendor patches or upgrade to fixed Tomcat releases immediately.
• Disable/limit HTTP methods like PUT and DELETE if not required.
• Enable Java serialization filtering and test application behavior.
• Harden file and network permissions, and monitor logs for suspicious requests.
• If compromise is suspected, follow incident response steps (isolate, preserve, analyze, remediate).

Additional resources and references

• Apache Tomcat — official website and security advisories (always consult the vendor page for the canonical fix)
• Independent analysis and writeups describing the vulnerability class (safe to consult for defensive context)
• Vendor-provided upgrade instructions and mitigation guidance (follow these first)

Note: This article focuses on defensive information and remediation. It avoids publishing exploit code or step‑by‑step exploitation instructions to prevent misuse. If you are responsible for Tomcat servers, follow the vendor guidance and apply patches promptly.