Home / Vulnerability Management / 🚨 CVE-2025-24813: Apache Tomcat RCE – Deep Dive & Live Demo

🚨 CVE-2025-24813: Apache Tomcat RCE – Deep Dive & Live Demo

Date Published: April 2025
Author: PinewoodSec Research Team

Introduction

On March 10, 2025, the Apache Software Foundation issued a security advisory for CVE-2025-24813β€”a critical vulnerability in Apache Tomcat affecting how partial PUT requests interact with file-based session storage. In specific configurations, this flaw can lead to remote code execution (RCE) via insecure Java object deserialization.

In this post, we provide a detailed breakdown of the vulnerability, highlight the underlying code paths, and demonstrate the exploit in a controlled environment using our custom lab applicationβ€”PinewoodStore.

Vulnerability Overview

CVE-2025-24813 allows attackers to manipulate how Tomcat handles PUT requests with the Content-Range header, triggering code that creates temporary files. When session persistence is enabled with FileStore, this leads to unsafe deserialization from attacker-controlled files.

Prerequisites for Exploitation

To exploit this vulnerability, the following server configurations must be in place:

  1. Writable DefaultServlet: The readonly init-param must be set to false in Tomcat’s web.xml: <init-param> <param-name>readonly</param-name> <param-value>false</param-value> </init-param>
  2. Partial PUT Support: Enabled by default via the doPut() method in Tomcat’s DefaultServlet.
  3. File-Based Session Persistence: Tomcat must use the PersistentManager with a FileStore backend: <Manager className=”org.apache.catalina.session.PersistentManager” maxIdleBackup=”1″ saveOnRestart=”true” processExpiresFrequency=”1″> <Store className=”org.apache.catalina.session.FileStore”/> </Manager>
  4. Full RCE would require the attacker finding ways to upload to server any java class files required to successfully deserialize the java objects. Example if the exploit is created using ysoserial tool then for effective exploitation the Tomcat code should be able to have access to the common collections package that the exploit is created from. Tomcat loads sessions using its WebappClassLoader, which only knows about classes in: /WEB-INF/classes/and /WEB-INF/lib/*.jar If the classes used by the Exploit are not accessible to Tomcat Application then it would throw an exception and the exploit won’t complete

πŸ“¦ Apache Tomcat Session Manager

πŸ”Ή What is the Session Manager?

  • It’s the component in Tomcat responsible for managing HTTP sessions.
  • Handles creation, tracking, timeout, and persistence of session data.
  • Every Context (web application) can define its own Manager element in context.xml.

πŸ”Ή Default Manager (StandardManager)

  • Class: org.apache.catalina.session.StandardManager
  • Stores sessions in memory.
  • Optionally writes session data to disk during shutdown or failover.
  • Not suitable for large-scale applications due to memory limitations.

πŸ”Ή PersistentManager

  • Class: org.apache.catalina.session.PersistentManager
  • Supports session persistence to disk (or other storage) using a Store implementation.
  • Can save and reload sessions across server restarts.
  • Requires a configured Store, like: <Manager className=”org.apache.catalina.session.PersistentManager”> <Store className=”org.apache.catalina.session.FileStore”/> </Manager>

πŸ”Ή Store Implementations

  • FileStore: Stores session objects as files on disk.
  • JDBCStore: Stores session data in a database (less common).
  • Custom stores can be created by implementing Store interface.

πŸ”Ή Security Implications

  • Serialized session objects are stored on disk.
  • If attacker-controlled data is deserialized without validation, RCE may occur (e.g., CVE-2025-24813).
  • Storing sessions as serialized Java objects opens the door to deserialization attacks.

Vulnerable Code Path

The vulnerable method in Tomcat is executePartialPut() in DefaultServlet.java, where a temporary file is created from the request path:

File tempDir = (File) getServletContext().getAttribute(ServletContext.TEMPDIR);
String convertedResourcePath = path.replace('/', '.');
File contentFile = new File(tempDir, convertedResourcePath);
if (contentFile.createNewFile()) {
    contentFile.deleteOnExit();
}

The attacker can supply a crafted partial PUT request with a malicious serialized session object to place a .session file in the work/Catalina/localhost/<app> directory.

Exploit Workflow

  1. Prepare a Malicious Serialized Session File: Example filename: malicious.session
  2. Determine File Size: Using Python: python3 -c “print(len(open(‘malicious.session’, ‘rb’).read()))”
  3. Craft the PUT Request: PUT /foo HTTP/1.1 Host: target Content-Range: bytes 0-47/48 Content-Length: 48 <binary contents of malicious.session>
  4. Trigger Deserialization: Restarting the Tomcat server causes the persistent session to load and deserialize the payload.

Affected Versions

The following versions of Apache Tomcat are affected by CVE-2025-24813:

  • Apache Tomcat 11.0.0-M1 to 11.0.2
  • Apache Tomcat 10.1.0-M1 to 10.1.34
  • Apache Tomcat 9.0.0.M1 to 9.0.98

Patched Versions

The issue is resolved in the following versions:

  • Apache Tomcat 11.0.3 and above
  • Apache Tomcat 10.1.35 and above
  • Apache Tomcat 9.0.99 and above

Administrators are strongly advised to upgrade to the latest patched release appropriate for their Tomcat deployment.

Troubleshooting

If you encounter an HTTP 405 error like:

JSPs only permit GET, POST or HEAD…

…you may be hitting a JSP resource instead of DefaultServlet. Ensure your PUT is targeting a non-mapped static path like /dummy, and not a .jsp.

Live Demo in PinewoodStore πŸ§ͺ

To showcase this vulnerability, we’ve built PinewoodStore, a vulnerable lab environment running Tomcat 10.0.27 with the required configuration.

The demo includes:

  • Writable DefaultServlet
  • File-based session storage
  • A vulnerable endpoint for uploading session files

Once the malicious .session file is placed correctly via a crafted PUT, deserialization is triggered within seconds, achieving code execution without needing to restart the server.

PinewoodStore web.xml inside WEB-INF

<servlet>
    <servlet-name>default</servlet-name>
    <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
    <init-param>
        <param-name>readonly</param-name>
        <param-value>false</param-value>
    </init-param>
</servlet>

PinewoodStore context.xml inside META-INF

<Context>
    <Manager className="org.apache.catalina.session.PersistentManager" 
             maxIdleBackup="1" 
             saveOnRestart="true" 
             processExpiresFrequency="1">
        <Store className="org.apache.catalina.session.FileStore" />
    </Manager>
</Context>

Mitigation

  • Set readonly to true in DefaultServlet.
  • Disable partial PUT if not needed.
  • Avoid using PersistentManager with FileStore unless absolutely necessary.
  • Always validate and restrict deserialization sources.

Final Thoughts

CVE-2025-24813 is a reminder of the dangers posed by deserialization and misconfigured server components. While not exploitable by default, a handful of changes can convert a benign setup into a critical vulnerability.

We highly recommend updating to the patched version once available and auditing your Tomcat deployments for the listed risk factors.

Stay secure, and happy hacking β€” responsibly!
πŸ”’ PinewoodSec Team

Tagged:

Leave a Reply

Your email address will not be published. Required fields are marked *