CVE-2026-68569

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-68569) has been identified in Apache Tomcat, which allows attackers to be authenticated as a user that has no entry in the realm's database. When a web application is configured with a DataSourceRealm or a JDBCRealm and uses an authentication mechanism that establishes the user name out of band and then only looks that name up in the realm, the realm returned a valid principal for every name it was given, so the lookup that was meant to confirm the user exists could never fail.

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 8.5.x versions of Apache Tomcat, including the NES-supported 8.5.x line.

Module Info

• Product: Apache Tomcat
• Affected packages: org.apache.tomcat:tomcat-catalina, 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 and https://central.sonatype.com/artifact/org.apache.tomcat.embed/tomcat-embed-core
• Package manager: Maven
• Fixed in: NES for Apache Tomcat 8.5.100-tomcat-8.5.110 (upstream fixed in Apache Tomcat 9.0.121, 10.1.59, and 11.0.25)

Vulnerability Info

This High-severity vulnerability is found in the org.apache.tomcat:tomcat-catalina package in all 8.5.x versions of Apache Tomcat. The getPrincipal(String) method of org.apache.catalina.realm.DataSourceRealm constructs and returns a GenericPrincipal for whatever user name it is handed, with no check that the user exists and no check on the values the lookup returned:

@Override
protected Principal getPrincipal(String username) {
    Connection dbConnection = open();
    if (dbConnection == null) {
        return new GenericPrincipal(username, null, null);
    }
    try {
        return new GenericPrincipal(username, getPassword(dbConnection, username),
                getRoles(dbConnection, username));
    } finally {
        close(dbConnection);
    }
}

For a name that has no row in the user table, getPassword(...) and getRoles(...) both return null, and those nulls are passed straight into the GenericPrincipal constructor, producing a fully formed, authenticated principal. The first branch is the same failure applied to infrastructure: when open() cannot obtain a database connection, the method still returns a principal, so a database outage authenticates every name that reaches it. The org.apache.catalina.realm.JDBCRealm class carries the identical defect in a single line:

@Override
protected synchronized Principal getPrincipal(String username) {
    return new GenericPrincipal(username, getPassword(username), getRoles(username));
}

Two authentication mechanisms reach this method: CLIENT-CERT and SPNEGO/GSS-API. Both establish the user name outside the realm and then ask the realm only to look it up. RealmBase.authenticate(X509Certificate[]) checks the certificate validity dates, and only when the realm is configured to validate them, before calling the realm with the name the X.509 username retriever extracts, which is the certificate's subject distinguished name by default. The SPNEGO path passes the authenticated GSSName through to the same realm method. In both cases the comment in RealmBase that describes checking the existence of the client principal in the database describes a check the realm never performed, so any certificate the connector's truststore accepts, and any principal from a trusted Kerberos realm, is authenticated as itself whether or not that user exists.

BASIC, FORM, and DIGEST authentication are not affected. BASIC and FORM are handled by DataSourceRealm.authenticate(String, String), which reads the stored credentials for the user first and returns no principal when they are absent, so an unknown user is rejected before getPrincipal runs. DIGEST does not reach that method at all: DataSourceRealm does not override the digest overload, so the request is handled by RealmBase, which resolves the stored digest for the user, returns no principal when there is none, and calls getPrincipal only after the digest comparison has already succeeded.

The impact is bounded by the role model, because a principal forged this way carries no roles: a security constraint that names a concrete role still denies the request. What the defect breaks is every configuration in which being authenticated is itself the decision, including an <auth-constraint> that uses <role-name>*</role-name> to admit any authenticated user, configurations that rely on allRolesMode, authentication-only realms that define no role store at all, and any application that trusts request.getUserPrincipal() or request.getRemoteUser() to identify the caller. Only DataSourceRealm and JDBCRealm are affected; the other realms shipped with Apache Tomcat, including MemoryRealm, UserDatabaseRealm, JNDIRealm, JAASRealm, CombinedRealm, and LockOutRealm, return no principal for a user they cannot find. The Apache Tomcat security team rates this issue Important and published no CVSS vector for it.

The unguarded principal construction is present in the earliest DataSourceRealm revision in the Apache Tomcat project history, which dates to 2006, and in every tagged release from Apache Tomcat 7.0.0 through Apache Tomcat 8.5.100. Apache declares this issue to affect Apache Tomcat from 7.0.0 onward and records versions before 7.0.0 as unknown.

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

• No individual finder is publicly credited for this issue.