CVE-2025-55668

Overview

Apache Tomcat is an open-source implementation of the Jakarta Servlet, Jakarta Pages, Jakarta Expression Language, Jakarta WebSocket, Jakarta Annotations, and Jakarta Authentication specifications. It serves Java web applications either as a standalone servlet container and HTTP server or embedded inside an application through the tomcat-embed-core artifact. Its Catalina servlet container (org.apache.tomcat:tomcat-catalina) supplies the request-processing pipeline, including Valves such as RewriteValve, along with connectors, realms, and session management.

A session fixation vulnerability (CVE-2025-55668) has been identified in the RewriteValve of Apache Tomcat, which allows attackers to craft a URL that, when a victim follows it, makes the victim's interaction with the target web application take place in the attacker's session.

Per OWASP: Session Fixation is an attack that permits an attacker to hijack a valid user session.

This issue affects multiple versions of Apache Tomcat.

Details

Module Info

• Product: Apache Tomcat
• Affected packages: org.apache.tomcat:tomcat-catalina, org.apache.tomcat.embed:tomcat-embed-core
• Affected versions: >=9.0.0.M1 <9.0.106, >=10.1.0-M1 <10.1.42, >=11.0.0-M1 <11.0.8
• GitHub repository: https://github.com/apache/tomcat
• Published packages: https://central.sonatype.com/artifact/org.apache.tomcat/tomcat-catalina, https://central.sonatype.com/artifact/org.apache.tomcat.embed/tomcat-embed-core
• Package manager: Maven
• Fixed in:
• OSS Apache Tomcat 9.0.106, 10.1.42, 11.0.8
• NES for Apache Tomcat v8.5.115

Vulnerability Info

This Medium-severity vulnerability is found in the org.apache.tomcat:tomcat-catalina and org.apache.tomcat.embed:tomcat-embed-core packages in multiple versions of Apache Tomcat. When RewriteValve applies a rule that rewrites a request internally (without the [R] redirect flag), it clears the request's mapping data and sends the rewritten request back through the connector's adapter, so it can be mapped again, possibly to a different web application:

request.getMappingData().recycle();
// Reinvoke the whole request recursively
Connector connector = request.getConnector();
try {
    if (!connector.getProtocolHandler().getAdapter().prepare(request.getCoyoteRequest(),
            response.getCoyoteResponse())) {
        return;
    }
} catch (Exception e) {
    // This doesn't actually happen in the Catalina adapter implementation
}
Pipeline pipeline = connector.getService().getContainer().getPipeline();
request.setAsyncSupported(pipeline.isAsyncSupported());
pipeline.getFirst().invoke(request, response);

Only the mapping data is reset. The session state the request picked up on its first pass (the requested session id, whether it came from the URL or a cookie, and any cached session) is left in place. When prepare() maps the rewritten URI, CoyoteAdapter only ever sets the requested session id: it reads a ;jsessionid= path parameter if the new web application allows URL session tracking, and then looks for a session cookie. It never clears a value that is already there:

String sessionID;
if (request.getServletContext().getEffectiveSessionTrackingModes().contains(SessionTrackingMode.URL)) {

    // Get the session ID if there was one
    sessionID = request.getPathParameter(SessionConfig.getSessionUriParamName(request.getContext()));
    if (sessionID != null) {
        request.setRequestedSessionId(sessionID);
        request.setRequestedSessionURL(true);
    }
}

// Look for session ID in cookies and SSL session
parseSessionCookiesId(request);

So a session id that the original web application accepted from the URL carries over into the target web application, even when the target only allows cookie session tracking and would reject that id if it arrived directly. Tomcat already resets session state for this reason when it re-maps a request to a different context version, but the rewrite path does not. An attacker who holds a valid session in the target application can send a victim a link such as http://host/<source-path>;jsessionid=<attacker session id>, where the source path is internally rewritten into the target application. The target application then serves the victim's request inside the attacker's session, so whatever the victim does there, such as submitting forms or entering data, happens in a session the attacker controls. Exploitation requires RewriteValve to be enabled (it is not by default) with a rule that rewrites internally from one web application into another, a source application that accepts URL session ids (the default), and a target application that does not. The same re-dispatch code, with no session reset, is present in the Apache Tomcat 8.5.x line.

Mitigation

Only recent versions of Apache Tomcat are community-supported. The community support version will not receive any updates to address this issue. For more information, see here. Apache Tomcat versions that are no longer community-supported are End-of-Life and have no publicly available fix.

Users of the affected components should apply one of the following mitigations:

• Upgrade to a patched version of Apache Tomcat.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• Greg K (finder)