CVE-2026-68525

Overview

Apache Tomcat is an open-source web server and servlet container, maintained by the Apache Software Foundation, that implements the Jakarta Servlet, Jakarta Pages (JSP), Jakarta Expression Language, and Jakarta WebSocket specifications and provides a pure-Java HTTP environment for running Java web applications.

An authorization bypass vulnerability (CVE-2026-68525) has been identified in Apache Tomcat, which allows an authenticated user to perform an HTTP method on a protected resource that the application reserves for a role the user does not hold. When a web application uses FORM authentication, Tomcat saves the request that triggered the login and replays it once the user has logged in, writing the saved HTTP method back onto the live request. The security constraints that govern the request are computed before authentication and are never recomputed afterwards, so the authorization decision is made against the method of the request that carried the post-login redirect rather than the method that is actually dispatched.

This is not exploitable in Apache Tomcat's default configuration. A vulnerable application must use FORM authentication and its security constraints must leave at least one HTTP method on a protected URL uncovered, so that the same URL is constrained for one method and genuinely unconstrained for another. A method-specific constraint on its own is not sufficient. The attacker must also complete a successful FORM login with valid credentials for an account that the constraint's role check would reject.

Per OWASP: Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user's limits.

This issue affects all versions of the Apache Tomcat 8.5.x line.

Module Info

• Product: Apache Tomcat
• Affected packages: org.apache.tomcat:tomcat-catalina (also bundled in the embedded org.apache.tomcat.embed:tomcat-embed-core)
• Affected versions: >=8.5.0 <=8.5.100
• GitHub repository: https://github.com/apache/tomcat
• Published packages: https://central.sonatype.com/artifact/org.apache.tomcat/tomcat-catalina
• Package manager: Maven
• Fixed in: NES for Apache Tomcat 8.5.100-tomcat-8.5.111 (upstream fixed in Apache Tomcat 9.0.121, 10.1.59, and 11.0.25)

Vulnerability Info

This Low-severity vulnerability is found in the org.apache.tomcat:tomcat-catalina package in all versions of the Apache Tomcat 8.5.x line. The flaw is an ordering problem in org.apache.catalina.authenticator.AuthenticatorBase, the valve that every authenticator extends, and it is reachable through org.apache.catalina.authenticator.FormAuthenticator.

AuthenticatorBase.invoke() determines which security constraints apply to the request once, before any authentication has taken place:

SecurityConstraint[] constraints = realm.findSecurityConstraints(request, this.context);

findSecurityConstraints() matches on the request's HTTP method, so the resulting constraint set is method-specific. Much later in the same method, after authentication has completed, that same local variable is what the authorization check consults:

if (constraints != null) {
    if (log.isTraceEnabled()) {
        log.trace("Calling accessControl()");
    }
    if (!realm.hasResourcePermission(request, response, constraints, this.context)) {
        ...
        return;
    }
}

Between those two points, FORM authentication can change the request's method. Tomcat saves the request that triggered the login form and, once credentials have been accepted, restores it onto the request that follows the login redirect, including the saved method:

String method = saved.getMethod();
...
request.getCoyoteRequest().method().setString(method);

The post-login redirect is a GET, and that GET reaches the authenticator even when it matches no constraint at all, because FormAuthenticator deliberately treats a request whose URI matches a saved request as one that still requires authentication. Its own comment names the scenario: "a resource is protected for some HTTP methods but not protected for GET which is used after authentication when redirecting to the protected resource."

The result is that the constraint set is computed from the redirect GET and then used to authorize a request that has since been turned back into the saved method. Where the GET matched no constraint, constraints is null, the authorization block is skipped entirely, hasResourcePermission() is never called, and the restored request is handed to the application without the role check the constraint demands. A user who logs in with valid credentials for a lower-privileged account can therefore perform a method that the application restricts to a role that user does not hold.

Exploitation requires a specific application configuration that Apache Tomcat does not ship. The application must use FORM authentication (<auth-method>FORM</auth-method>), and its security constraints must leave at least one HTTP method on a protected URL uncovered: a <web-resource-collection> that names specific <http-method> elements with no companion <http-method-omission> constraint denying the remaining methods, so the same URL is constrained for one method and unconstrained for another. The attacker must hold valid credentials for an account that fails the constraint's <auth-constraint> role check, and the attack begins with a successful login as that user. None of the web applications bundled with Apache Tomcat meet these conditions: the only bundled application that uses FORM authentication pairs its <http-method> list with an <http-method-omission> constraint that denies every other method, so no method is left uncovered. The Apache Tomcat security team rates this issue Low and published no CVSS vector for it.

Apache declares this issue to affect Apache Tomcat from 7.0.0 onward and records versions before 7.0.0 as unknown, and the affected code is present in every release of the 8.5.x line, from 8.5.0 through the final community release 8.5.100.

Mitigation

Only recent major lines of Apache Tomcat are community-supported. The affected 8.5.x line reached End-of-Life on March 31, 2024 (final community release 8.5.100) and will not receive public updates to address this issue.

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

• Upgrade to a currently supported Apache Tomcat major line (9.0.x or later) that contains the fix.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• 4ra1n (finder)
• pyn3rd (finder)
• unam4 (finder)