Cenobe Cyber Security

Despite claims of active exploitation, we found that the conditions required are so rare and complex that most real-world environments are likely unaffected. Here’s what we discovered, and why this matters.

A Chain of Rare Prerequisites

For this exploit to succeed, three specific things must all be true at once — and they almost never are in production environments.

1. DefaultServlet must be enabled (rarely occurs)

The Default Servlet is a built-in servlet provided by the Apache Tomcat server. It serves as the fallback servlet for handling static resources (like HTML files, images, CSS, JavaScript, etc.) in a web application when no other servlet matches the request.

It is implemented by org.apache.catalina.servlets.DefaultServlet

As configured initially, it is not enabled, which means when we use the PUT method on the endpoint /random_endpoint, it returns “405 - Method Not Allowed”

To be enabled, it is required to add

<init-param>
<param-name>readonly</param-name>
<param-value>false</param-value>
</init-param>

To the configuration of the default servlet

Because it assigns this.readOnly to this.getServletConfig().getInitParameter("readonly")

When it is configured, we can use the PUT, DELETE methods for our purpose

And a file random_endpoint with the content something_here will be created (or modified if it exists) under the application folder

We don’t usually see this feature enabled in the production environment, as it is vulnerable to many other types of attack. An attacker doesn’t need to exploit this tough vulnerability because he has many options.

2. File-based session must be enabled (barely happens)

File-based session in Tomcat refers to the way Tomcat persists HTTP session data by saving session information to files on disk, rather than keeping it only in memory.

We should consider using file-based session in Tomcat when we need basic session survival across server restarts, but do not require high scalability or distributed clustering.

This option is irrelevant for nearly all applications. Few have a reason to enable it, as it's difficult to scale and lacks practical use cases.

To enable it, we need to set up things in context.xml

When we send a request with the header Cookie: JSESSIONID=aaa

The server will read the file <web-root>+<storageDir>+JSESSIONID+.session

And then deserialize it with readObject() method.

Combined with the PUT request above, we can technically upload a payload to /<storageDir>/something.session, then trigger the deserialization process by sending a normal request with the header Cookie: JSESSIONID=something

Not to mention, the attacker also needs to know the storageDir, which means the directory value in the config file. It is impossible if it is not /, right?

3. A valid gadget chain

The vulnerable versions of Tomcat are recent versions, which means most of them are based on Java 17 or higher.

I attempted to run these versions using Java 11; however, the process consistently failed due to version incompatibility, resulting in repeated exceptions.

You know what, a high amount of known gadget chains (from ysoserial) are based on Java 11 or lower, you will get many exceptions if you use these gadgets for testing, ClassNotFoundException for example. Attacking Java deserialization by blackbox testing is no longer possible nowadays.

URLDNS gadget may still work to verify the exploit theory, but a DNS request is not enough to prove the impact.

TL;DR — Why You Probably Aren’t Vulnerable

To actually exploit CVE-2025-24813, an attacker would need:

Writable DefaultServlet
File-based session storage with known path
Valid gadget chain compatible with modern Java

All three at once? Extremely unlikely.

Our Recommendations

That said, staying ahead is always wise. Here’s how to stay safe:

Disable or lock down the DefaultServlet
Avoid using file-based sessions
Use randomized or obscure session file paths
Block /*.session requests at the WAF
Scan for serialized payloads (AC ED 00 05) in HTTP bodies

Final Thoughts

While the CVSS score is high, the real-world risk is low for most setups. We believe this vulnerability sparked more fear than it should and our R&D work confirms it.

Exploitation is not impossible but it’s definitely not plug-and-play.

If your team wants real clarity, real guidance, and real protection talk to us.

Our R&D team doesn’t just read CVEs. We break them down, test them, and tell you the truth.