Apache Tomcat servers are in trouble again.
The API security firm Wallarm posted an announcement last week titled "One PUT Request to Own Tomcat: CVE-2025-24813 RCE is in the Wild". They wrote:
A devastating new remote code execution (RCE) vulnerability, CVE-2025-24813, is now actively exploited in the wild. Attackers need just one PUT API request to take over vulnerable Apache Tomcat servers. The exploit, originally published by a Chinese forum user iSee857, is already available online.
So here's what we know: This newly disclosed attack leverages Tomcat's default session persistence mechanism along with its support for partial PUT requests. Tomcat is Apache's Java web application server that provides a "pure Java" HTTP web server environment in which Java code can run. This new exploit works within this environment, requiring just two simple steps.
First, the attacker starts by sending a PUT request to upload a malicious session file to the server. The payload is a base64-encoded ysoserial gadget chain that's designed to trigger remote code execution when it's deserialized. This initial PUT 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. So the first step essentially causes the Apache Tomcat server to upload and store the attacker's Java attack file.
Then, with the session file is uploaded, the attacker triggers deserialization of that file by sending a simple GET request by providing a JSESSIONID cookie which points to the malicious session:
GET / НTTP/1.1
Host: vulnerable.host:8080
Cookie: JSESSIONID=¡See857
Seeing this Session ID, Tomcat dutifully retrieves the stored file, deserializes it, and executes the embedded Java code, which typically grants full remote access to the attacker.
This is about as horrible as a remote attack can get because it's dead simple to execute, requires no authentication and very little imagination. The only technical requirement is that the Tomcat server is using file-based session storage, which is common in many deployments. Also, the use of base64 encoding allows the exploit to bypass traditional security filters, making detection somewhat more challenging. And, of course, you need to know to look for it in the first place.
Wallarm detected the first attack in the early afternoon of Mar 12, Central Standard Time, originating from Poland a few days before the first public exploit was released on GitHub.
And the Wallarm folks caution about the future, writing:
While this exploit abuses session storage, the bigger issue is partial PUT handling in Tomcat, which allows uploading practically any file anywhere. Attackers will soon start shifting their tactics, uploading malicious JSP files, modifying configurations, and planting backdoors outside session storage. This is just the first wave.
The reality is that reactive security-waiting for CVEs, adding Web Application Firewall rules, and hoping logs will catch threats-is a losing game. CVE-2025-24813 went from disclosure to public exploit in just 30 hours.
That's not time for Apache's Tomcat team to get up to speed and patch, let alone test and deploy a critical update... to say nothing of having those updates deployed and servers patched.
NIST's National Vulnerability Database concurs about the severity of CVE-2025-24813 assigning it the maximum common CVSS severity rating of 9.8 and formally labeling it "CRITICAL".
The global inventory of these Apache Tomcat servers appears to be somewhere just short of around nineteen thousand installations. That's not a huge amount of global exposure, but they are likely to be running in enterprises that would qualify as prime targets.
Our takeaway here is the refrain that security is difficult and features will almost always come back to bite you in the butt.
