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: CVE-2025-24813 PoC by iSee857.

Exploit Breakdown: How a Simple PUT Request Leads to Full RCE

This attack leverages Tomcat’s default session persistence mechanism along with its support for partial PUT requests. The exploit works in two steps:

1. The attacker uploads a serialized Java session file via PUT request
2. The attacker triggers deserialization by referencing the malicious session ID in a GET request

Step 1: Uploading a Malicious Serialized Session

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, 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 deserialize

Step 2: Triggering Execution via Session Cookie

Once the session file is uploaded, the attacker triggers deserialization by sending a simple GET request with the JSESSIONID pointing to the malicious session.

GET / HTTP/1.1
Host: vulnerable.host:8080
Cookie: JSESSIONID=iSee857

Tomcat, seeing this session ID, retrieves the stored file, deserializes it, and executes the embedded Java code, granting full remote access to the attacker.

Why This Exploit is So Dangerous

This attack is dead simple to execute and requires no authentication. The only requirement is that Tomcat is using file-based session storage, which is common in many deployments. Worse, base64 encoding allows the exploit to bypass most traditional security filters, making detection challenging.

Why Traditional WAFs Fail

• Most Web Application Firewalls (WAFs) completely miss this attack because:
• The PUT request looks normal and doesn’t contain obvious malicious content.
• The payload is base64-encoded, preventing pattern-based detection.
• The attack is two-step, where the harmful part only executes during deserialization.

Most WAFs do not deeply inspect uploaded files or track multi-step exploits.

This means that by the time an organization detects the breach in its logs, it’s already too late.

How Wallarm Blocks This Attack in Real-Time

Unlike traditional WAFs, Wallarm’s API security platform detects and blocks these threats automatically, with no manual tuning required. It does this by:

1. Decoding base64 payloads before analysis, revealing hidden attacks.
2. Unpacking and inspecting serialized Java objects, detecting ysoserial exploits instantly.
3. Tracking multi-step attacks, recognizing when a session file upload leads to code execution.
4. Blocking malicious API requests in real-time, preventing the session file from ever being used.

The Future of CVE-2025-24813: More RCEs Incoming

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 WAF rules, and hoping logs will catch threats—is a losing game. CVE-2025-24813 went from disclosure to public exploit in just 30 hours. The only effective defense is real-time API security that blocks threats as they happen.

Real-Time API Security: The Only Way Forward

Organizations need to rethink security beyond legacy WAFs and post-breach forensic analysis. The solution lies in real-time detection, automated decoding, and deep inspection. Wallarm’s proactive security ensures that:

1. Every request is deeply analyzed, not just pattern-matched.
2. Payloads are decoded and unpacked, exposing hidden exploits.
3. Multi-step attacks are blocked, even when obfuscation is used.

CVE-2025-24813 is just the beginning. Attackers are evolving, and security must evolve faster. With Wallarm, organizations stay ahead of the threat curve—not one exploit behind. Ready to start with API security? Get Wallarm product tour now!