'Dead simple' hijacking hole in Apache Tomcat 'now actively exploited in the wild'

One PUT request, one poisoned session file, and the server’s yours

Updated A trivial flaw in Apache Tomcat that allows remote code execution and access to sensitive files is said to be under attack in the wild within a week of its disclosure.

The vulnerability is CVE-2025-24813, and was revealed on March 10 along with updates to close the hole in the open source web server software. According to API security shop Wallarm, an exploit for the bug was publicly distributed 30 hours later, and is “now actively exploited in the wild.”

Authentication is not required to pull off an attack, and the end result is the ability to run arbitrary code on the targeted Tomcat server by miscreants, allowing them to access data among other nefarious things.

"We've already seen this in operation by Chinese operators, and CISA [The US government's Cybersecurity and Infrastructure Security Agency] got in touch tonight and are going to add the exploit to its warning list," Ivan Novikov, Wallarm's CEO, told The Register.

According to a Wallarm advisory about the flaw, the only requirement for successful exploitation “is that Tomcat is using file-based session storage, which is common in many deployments.”

“The attacker starts by sending a PUT request to upload a malicious session file to the server,” Wallarm’s advisory explains.

"The payload is a base64-encoded ysoserial gadget chain, designed to trigger remote code execution when deserialized. This request writes a file inside Tomcat’s session storage directory. Because Tomcat automatically saves session data in files, the malicious payload is now stored on disk, waiting to be deserialized.”

To deserialize the payload, attackers need only send a GET request with the JSESSIONID pointing to the malicious session. “Tomcat, seeing this session ID, retrieves the stored file, deserializes it, and executes the embedded Java code, granting full remote access to the attacker,” Wallarm’s advisory states.

The Apache Foundation’s advisory on the matter rates this an “important” flaw. The foundation doesn’t assign CVSS scores – preferring to provide details that allow users to make their own decisions about how to act.

The org points out that successful exploitation of the flaw to achieve remote code execution requires four conditions to be met, including two default settings in Tomcat - writes enabled to the default servlet and support for partial PUT uploads. The other two conditions are an application configured to use Tomcat's file based session persistence with the default storage location and including a library that may be leveraged in a deserialization attack.

That's a decent set of hurdles though crims may find the course worthwhile as Apache Tomcat is widely used to deploy bespoke Java applications inside enterprises. Such apps store the kind of juicy data and code network intruders love to pillage. Running Tomcat in read-only mode for the default servlet has been a good idea since at least 2017.

The flaw is present in Apache Tomcat versions 11.0.0-M1 through 11.0.2, from 10.1.0-M1 through 10.1.34, and from 9.0.0.M1 through 9.0.98.

The flaw can also be used to view or tamper with sensitive files. That scenario requires five conditions to be met:

1. Writes enabled for the default servlet (disabled by default)
2. Support for partial PUT (enabled by default)
3. A target URL for security sensitive uploads that was a sub-directory of a target URL for public uploads
4. Attacker knowledge of the names of security sensitive files being uploaded
5. The security sensitive files also being uploaded via partial PUT

We've asked Apache for more info and will update this story if the org responds. ®

Updated to add at 1430 UTC

Amid active exploitation, Apache is sure most users won't be at risk.

"Given the prerequisites for an Apache Tomcat installation to be vulnerable to CVE-2025-24813, the Tomcat project is of the view that the vast majority of Tomcat installation will not be affected," Mark Thomas, one of the project management committee members for the Apache Tomcat project, told The Register.

"Tomcat does not include any form of telemetry so we have no way to determine how many users are running any particular version of Tomcat nor what configuration settings they are using," he added. "We do have access to anonymized download statistics, but those are heavily distorted by what looks like downloads for CI systems."