A critical path equivalence vulnerability in Apache Tomcat, designated CVE-2025-24813, has been actively exploited in the wild following the public release of proof-of-concept exploit code. 

The vulnerability, disclosed on March 10, 2025, enables unauthenticated remote code execution under specific server configurations and affects millions of Java-based web applications worldwide. 

Security researchers have confirmed active exploitation attempts shortly after the vulnerability’s disclosure, with the Cybersecurity and Infrastructure Security Agency (CISA) adding it to the Known Exploited Vulnerabilities catalog on April 1, 2025.

CVE-2025-24813: Apache Tomcat Path Equivalence Vulnerability

CVE-2025-24813 represents a path equivalence vulnerability that exploits how Apache Tomcat processes file paths internally, specifically affecting the server’s handling of partial PUT requests and session file persistence. 

The vulnerability impacts a broad range of Apache Tomcat versions, including 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. 

Additionally, security researchers at Recorded Future discovered that 8.5.x versions (specifically 8.5.0 to 8.5.98 and 8.5.100, excluding 8.5.99) are also vulnerable, though these were not included in Apache’s initial advisory.

The vulnerability stems from improper handling of HTTP requests that permit unauthorized access to restricted directories and sensitive files. 

When exploited successfully, attackers can achieve remote code execution, severe information leakage, or malicious content injection that can corrupt critical server configuration files. 

The flaw specifically affects how the server processes file paths internally, where slashes are converted to dots in the DefaultServlet’s path mapping logic.

Successful exploitation of CVE-2025-24813 requires a specific set of prerequisites that make the vulnerability less likely to be exploitable in default configurations. 

The attack requires the default servlet’s readonly attribute to be set to false, permitting write access via HTTP PUT requests, though this setting is disabled by default.

Additional requirements include enabling partial PUT functionality, file-based session persistence with default storage location, and the presence of a deserialization-vulnerable library within the application.

The attack methodology involves a two-step process where attackers first upload a malicious serialized Java payload using a PUT request to a path like /random/session, which Tomcat internally maps to a file named .random.session. 

Subsequently, attackers send a GET request with a specially crafted JSESSIONID cookie referencing the malicious session, causing the server to deserialize the payload and execute arbitrary code. 

Security researchers have observed common attack payloads targeting *.session file paths with randomized naming schemes consisting of six-character bases appended with the .session file extension.

Proof-of-Concept 

Public proof-of-concept exploit code has been released on GitHub, significantly lowering the barrier for potential attackers. 

The PoC demonstrates the complete attack chain, utilizing tools like ysoserial to generate malicious serialized payloads and execute commands such as whoami or curl for remote communication. 

The exploit code includes functionality to test server writability via PUT requests and automatically generates session IDs for payload delivery.

Organizations must immediately upgrade to patched versions: Apache Tomcat 11.0.3, 10.1.35, or 9.0.99 to address this vulnerability. 

Additional mitigation strategies include disabling unnecessary HTTP methods, enforcing strict access controls, and deploying Web Application Firewalls (WAFs) with specific rules to detect CVE-2025-24813 exploitation attempts. 

Akamai has automatically deployed Adaptive Security Engine Rapid Rules to protect App & API Protector customers, while providing Guardicore Segmentation Insight queries for detection.

Despite the availability of exploit code, researchers note that the specific configuration requirements make broad exploitation unlikely, with GitHub code searches revealing only approximately 200 open-source Tomcat projects using write-enabled default servlet configurations

Find this News Interesting! Follow us on Google News, LinkedIn, & X to Get Instant Updates!