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. However, 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’s post 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.

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. ®