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.
# Dockerfile
# Stage 1: Build stage to copy web apps and make modifications
FROM tomcat:11.0.1 as build
# Copy the necessary configuration files
COPY ./web.xml /usr/local/tomcat/conf/web.xml
COPY ./context.xml /usr/local/tomcat/conf/context.xml
COPY ./commons-collections-3.2.1.jar /usr/local/tomcat/lib/
# Copy web applications (ROOT and manager) from the `webapps.dist` folder inside the container
RUN mkdir -p /usr/local/tomcat/webapps/ROOT && \
cp -r /usr/local/tomcat/webapps.dist/ROOT/* /usr/local/tomcat/webapps/ROOT && \
cp -r /usr/local/tomcat/webapps.dist/manager /usr/local/tomcat/webapps/manager && \
sed -i 's/allow="[^"]*"/allow=".*"/' /usr/local/tomcat/webapps/manager/META-INF/context.xml && \
sed -i '/<\/tomcat-users>/d' /usr/local/tomcat/conf/tomcat-users.xml && \
echo ' <role rolename="manager-gui"/>' >> /usr/local/tomcat/conf/tomcat-users.xml && \
echo ' <role rolename="admin-gui"/>' >> /usr/local/tomcat/conf/tomcat-users.xml && \
echo ' <user username="admin" password="admin" roles="manager-gui,admin-gui"/>' >> /usr/local/tomcat/conf/tomcat-users.xml && \
echo '</tomcat-users>' >> /usr/local/tomcat/conf/tomcat-users.xml
# Stage 2: Final image to run Tomcat
FROM tomcat:11.0.1
# Copy from the build stage
COPY --from=build /usr/local/tomcat/webapps /usr/local/tomcat/webapps
COPY --from=build /usr/local/tomcat/conf /usr/local/tomcat/conf
COPY --from=build /usr/local/tomcat/lib /usr/local/tomcat/lib
# Expose the necessary port
EXPOSE 8080
# Start Tomcat in the foreground
CMD ["catalina.sh", "run"]
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.
