How to Protect Your Servers

General
1

A severe security vulnerability in Apache Tomcat has system administrators scrambling to patch their servers. The flaw, tracked as CVE-2025-24813, allows attackers to execute malicious code remotely on affected systems without authentication. Let’s dive into the details of this vulnerability and explore how you can safeguard your Tomcat installations.

The Nature of the Vulnerability

CVE-2025-24813 stems from a path equivalence issue in Apache Tomcat’s handling of file uploads. When certain conditions are met, an attacker can exploit this flaw to upload and execute arbitrary code on the server.

The vulnerability affects the following Tomcat versions:

  • 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

For a Tomcat server to be vulnerable, several specific conditions must be true:

  1. The default servlet has write permissions enabled (disabled by default).
  2. Support for partial PUT requests is active (enabled by default).
  3. The application uses Tomcat’s file-based session persistence with the default storage location.
  4. The application includes a library that can be leveraged in deserialization attacks.

How the Exploit Works

The attack leverages a two-step process to achieve remote code execution:

Step 1: The attacker sends a specially crafted PUT request containing a malicious, serialized Java payload. This payload is saved as a session file in Tomcat’s storage directory.

Step 2: A follow-up GET request is sent with a JSESSIONID cookie pointing to the uploaded malicious session file. When Tomcat processes this request, it deserializes the session data without proper validation, executing the embedded malicious Java code.

This method bypasses many traditional security filters because the PUT request appears normal, and the payload is base64-encoded.

Mitigation Strategies

To protect your Tomcat installations from this vulnerability, consider implementing these measures:

Update to Patched Versions

The most effective way to address this vulnerability is to update your Tomcat installations to the following patched versions:

  • Apache Tomcat 11.0.3 or later
  • Apache Tomcat 10.1.35 or later
  • Apache Tomcat 9.0.99 or later

Disable Partial PUT Support

If immediate updating isn’t feasible, you can mitigate the risk by disabling support for partial PUT requests. Modify your conf/web.xml file:

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

Enforce Read-Only Mode for Default Servlet

Ensure the default servlet is set to read-only mode by modifying the readonly parameter in conf/web.xml:

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

Review Session Persistence Configuration

If possible, switch from file-based session persistence to an in-memory or database-backed solution. This change removes one of the key prerequisites for the vulnerability.

Audit Deployed Applications

Examine your deployed applications for libraries that could be exploited in deserialization attacks. Remove or update any potentially vulnerable components.

Detecting Exploitation Attempts

To identify potential exploitation attempts, monitor your Tomcat access logs for suspicious patterns:

  • Look for PUT requests to unexpected locations, especially those targeting the session storage directory.
  • Watch for GET requests with unusual JSESSIONID values, particularly those that don’t match your application’s normal session ID format.
  • Set up alerts for any 500 Internal Server errors that occur immediately after these suspicious request patterns.

Long-Term Security Considerations

While addressing this specific vulnerability is crucial, it’s also important to consider broader security measures for your Tomcat deployments:

  • Implement a Web Application Firewall (WAF) to provide an additional layer of protection against various attack vectors.
  • Regularly review and update your Tomcat configurations, ensuring that security-related settings are appropriately locked down.
  • Keep all components of your web application stack, not just Tomcat, up to date with the latest security patches.
  • Conduct periodic security audits and penetration testing to identify potential vulnerabilities before they can be exploited.

The discovery of CVE-2025-24813 serves as a reminder of the importance of staying vigilant with server security. By promptly applying patches and implementing additional security measures, you can significantly reduce the risk of exploitation and keep your Tomcat servers secure.