A newly discovered vulnerability in Apache Tomcat, tracked as CVE-2025-24813, is being actively exploited in the wild. This remote code execution (RCE) flaw allows attackers to take over servers with just two simple steps. This vulnerability (carrying an 8.6 severity score from RedHat) is difficult to detect with most traditional security tools. If your organization relies on Java applications running on Apache Tomcat, this should be an urgent priority.
The attack method is deceptively simple but highly effective. First, an attacker uploads a malicious Java session file using a PUT request, disguising it in base64 encoding so that most Web Application Firewalls (WAFs) and security filters don’t flag it as suspicious. Next, the attacker triggers the exploit using a GET request, referencing the uploaded session ID. This action forces the server to deserialize the malicious payload, giving the attacker full control over the system.
What makes this vulnerability particularly dangerous is its ability to bypass traditional security defenses. Many WAFs and Intrusion Detection Systems (IDS) rely on pattern matching, looking for known attack signatures. But because this attack unfolds in two stages, with the real malicious payload executing only at the very end, most security tools simply fail to recognize it as a threat. To make matters worse, no authentication is required for this exploit, meaning that any exposed Tomcat server using file-based session storage is a potential target.
Traditional Security Solutions Fail To Detect CVE-2025-24813
Most organizations rely on WAFs, IDS, and RASP solutions, but these tools analyze requests in isolation, missing multi-step attacks like this one. Additionally, base64 encoding presents another challenge. Many security tools rely on static signature detection, meaning they scan for recognizable patterns in HTTP requests. But with the payload obfuscated in base64 encoding, those tools simply don’t recognize the threat. By the time the malicious payload executes, it’s too late—the server is already compromised.
Even traditional RASP solutions struggle. Many monitor application behavior externally, but CVE-2025-24813 manipulates the internal Java execution process itself, making it invisible to tools that aren’t deeply integrated into the Java Virtual Machine (JVM).
This growing gap between security tool capabilities and modern attack techniques highlights a pressing need for a more advanced approach—one that secures Java applications at the execution level, rather than just scanning for known threats.
Waratek Stops CVE-2025-24813 Before It Can Execute
Waratek’s approach to Java security is fundamentally different. Rather than relying on external monitoring, Waratek integrates directly into the JVM, securing Java code at runtime.
Unlike WAFs and IDS systems, which monitor traffic at the perimeter, Waratek enforces security policies inside the application itself. Even if an attacker uploads a malicious session file, Waratek blocks deserialization before execution, detecting threats at the bytecode level—making it uniquely effective against Java-specific attacks like CVE-2025-24813.
A major advantage is virtual patching. Traditional patching requires code changes, testing, and redeployment, which forces downtime and can delay protection for weeks or months. Waratek applies security fixes instantly at runtime, eliminating vulnerabilities without modifying code.
Waratek’s Deserial and Process Forking rules provide an additional layer of protection against CVE-2025-24813 by preventing malicious file deserialization and unauthorized process execution. When an attacker attempts to trigger deserialization through a GET request, Waratek’s Deserial rule detects the suspicious session file and blocks execution before it can load into memory. Meanwhile, Waratek’s Process Forking rule prevents attackers from launching unauthorized child processes—effectively stopping any attempt to escalate privileges or execute remote commands. This ensures that even if a malicious file is uploaded, it can never be executed, neutralizing the exploit before it can cause harm. This means that for Waratek customers, CVE-2025-24813 is neutralized today—not months from now.
Finally, Waratek ensures minimal performance impact. Unlike traditional RASP solutions, which introduce latency and CPU overhead, Waratek operates natively inside the JVM, securing applications without slowing them down.
What Security Leaders Need to Do Next
For CISOs, security architects, and DevSecOps teams, the emergence of CVE-2025-24813 is a critical reminder that attackers are evolving faster than traditional security solutions. This vulnerability is already being exploited in the wild, and organizations that rely on Apache Tomcat need immediate protection.
Patching Apache Tomcat manually is an option, but it’s not a fast one. Even in organizations with strong patch management, applying updates across all production environments takes time, testing, and development resources—leaving critical systems vulnerable in the meantime. Waratek eliminates this window of exposure by securing Java applications at runtime, ensuring that exploits like CVE-2025-24813 can’t be weaponized, even if an application is technically still vulnerable.
Protecting against any one vulnerability shouldn’t be anyone’s end goal. Attackers are constantly refining their techniques, and eventually, someone will find a way to get into your system. Particularly when it comes to multi-step, obfuscated exploits like this one, detection is not going to be enough. Security teams need tools that don’t just detect threats, but can actively prevent them before they execute—without all the operational inconveniences that come with manual patching.
If your organization runs Apache Tomcat or other Java-based applications, now is the time to reassess whether your current security approach is built to handle these evolving threats.
Eliminate Apache Tomcat Vulnerabilities Today with Waratek
The next Apache Tomcat exploit may be even more sophisticated, harder to detect, or more damaging than CVE-2025-24813. Waiting for security tools to catch up isn’t an option. Waratek correlates multi-step attack sequences in real time, recognizing patterns and stopping threats before execution—a critical edge over security tools that analyze requests in isolation.
With Waratek, your Java applications stay protected, no matter how attackers evolve.
