Mar 17, 2025Ravie LakshmananVulnerability / Web Security

A recently disclosed security flaw impacting Apache Tomcat has come under active exploitation in the wild following the release of a public proof-of-concept (PoC) a mere 30 hours after public disclosure.

The vulnerability, tracked as CVE-2025-24813, affects the below versions –

• Apache Tomcat 11.0.0-M1 to 11.0.2
• Apache Tomcat 10.1.0-M1 to 10.1.34
• Apache Tomcat 9.0.0-M1 to 9.0.98

It concerns a case of remote code execution or information disclosure when specific conditions are met –

• Writes enabled for the default servlet (disabled by default)
• Support for partial PUT (enabled by default)
• A target URL for security sensitive uploads that is a sub-directory of a target URL for public uploads
• Attacker knowledge of the names of security sensitive files being uploaded
• The security sensitive files are also being uploaded via partial PUT

Successful exploitation could permit a malicious user to view security sensitive files or inject arbitrary content into those files by means of a PUT request.

Additionally, an attacker could achieve remote code execution if all the following conditions are true –

• Writes enabled for the default servlet (disabled by default)
• Support for partial PUT (enabled by default)
• Application was using Tomcat’s file based session persistence with the default storage location
• Application included a library that may be leveraged in a deserialization attack

In an advisory released last week, the project maintainers said the vulnerability has been resolved in Tomcat versions 9.0.99, 10.1.35, and 11.0.3.

But in a concerning twist, the vulnerability is already seeing exploitation attempts in the wild, per Wallarm.

“This attack leverages Tomcat’s default session persistence mechanism along with its support for partial PUT requests,” the company said.

“The exploit works in two steps: The attacker uploads a serialized Java session file via PUT request. The attacker triggers deserialization by referencing the malicious session ID in a GET request.”

Put differently, the attacks entail sending a PUT request containing a Base64-encoded serialized Java payload that’s written to Tomcat’s session storage directory, which subsequently gets executed during deserialization by sending a GET request with the JSESSIONID pointing to the malicious session.

Wallarm also noted that the vulnerability is trivial to exploit and requires no authentication. The only prerequisite is that Tomcat uses file-based session storage.

“While this exploit abuses session storage, the bigger issue is partial PUT handling in Tomcat, which allows uploading practically any file anywhere,” it added. “Attackers will soon start shifting their tactics, uploading malicious JSP files, modifying configurations, and planting backdoors outside session storage.”

Users running affected versions of Tomcat are advised to update their instances as soon as possible to mitigate potential threats.