Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Tomcat - CVE-2025-24813

CVE-2025-24813 is a potential RCE and/or information disclosure and/or information corruption with partial PUT.

An attacker could achieve remote code execution if all the following conditions are true -

  • Writes enabled for the default servlet (disabled by default)

  • Support for partial PUT (enabled by default)

  • Application was using Tomcat's file based session persistence with the default storage location

  • Application included a library that may be leveraged in a deserialization attack

The vulnerability affects both Windows and Linux based installation running any of the below Apache Tomcat versions:

  • 9.0.0.M1 <= Apache Tomcat <= 9.0.98

  • 10.1.0-M1 <= Apache Tomcat <= 10.1.34

  • 11.0.0-M1 <= Apache Tomcat <= 11.0.2

First available poc was published by iSee857 targeting a Windows installation, below is the Linux equivalent.

Setup test environment

To setup a test docker container we need to tweak the Dockerfile a little to include common-collections-x.x.x.jar, as well as the non-default configuration in web.xml and context.xml. 

<!-- web.xml (enable write for default servlet) -->
<init-param>
    <param-name>readonly</param-name>
    <param-value>false</param-value>
</init-param>

<!-- context.xml (file based session persistance with default storage location) -->
<Manager className="org.apache.catalina.session.PersistentManager">
    <Store className="org.apache.catalina.session.FileStore"/>
</Manager>

I decided to go with Tomcat version 11.0.1 in my test environment.

Verify vulnerability

Step 1: Uploading a Malicious Serialized Session

Create some random serialized data and upload it with PUT /anything/session. The payload is not important at this stage, we just want to verify that the target respond with HTTP 409.

If we login to the docker container we can see that the new serialized session is created in the directory /usr/local/tomcat/work/Cataline/localhost/ROOT.

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.

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

I've noticed during my testing that using CommonCollections6 (cc6) will result in a HTTP 500 response, while cc7 get HTTP 200 response. Both are valid and the payload is triggered as seen below, but I guess cc7 has the edge in terms of stealth.

POC || GTFO

Last updated