Vulnerability Directory | CVE-2026-55957

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-55957) has been identified in Apache Tomcat, which allows attackers to authenticate as a valid user without supplying that user's correct password. When JNDIRealm is configured to authenticate LDAP binds using GSSAPI, the per-user credential bind authenticates via the configured Kerberos/GSSAPI subject instead of the password the user supplied, yet the realm still marks the user as validated. An attacker who knows a valid username can therefore log in with an empty or incorrect password.

Per OWASP: Confirmation of the user's identity, authentication, and session management is critical to protect against authentication-related attacks.

This issue affects multiple versions of Apache Tomcat below 11.0.23.

‍

Details

Module Info

Product: Apache Tomcat
Affected packages: tomcat-catalina, tomcat-embed-core
Affected versions: >= 7.0.0 <=7.0.109, >=8.5.0 <=8.5.100, >=9.0.0.M1 <9.0.119, >=10.1.0-M1 <10.1.56, >=11.0.0-M1 <11.0.23
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:
- NES for Apache Tomcat 8.5.100-tomcat-8.5.107
- Apache Tomcat 11.0.23, 10.1.56, 9.0.119 (OSS)

Vulnerability Info

This High-severity vulnerability is found in the tomcat-catalina package in Apache Tomcat. The flaw lives in org.apache.catalina.realm.JNDIRealm, the realm implementation that authenticates users against an LDAP directory.

When a username and password are submitted, the realm validates them through checkCredentials(), which (on the path where no stored password attribute is read back) calls bindAsUser() to validate the password by performing an LDAP bind with the user's distinguished name and the supplied credentials:

userCredentialsAdd(context, dn, credentials);
// Elicit an LDAP bind operation
try {
    context.getAttributes("", null);
    validated = true;
} catch (AuthenticationException e) {
    // ...
}
userCredentialsRemove(context);
return validated;

userCredentialsAdd() sets only the Context.SECURITY_PRINCIPAL and Context.SECURITY_CREDENTIALS environment entries; it never touches Context.SECURITY_AUTHENTICATION. When the shared LDAP connection has been configured for an authenticated bind using GSSAPI (the connection's Context.SECURITY_AUTHENTICATION is set to GSSAPI, for example through the realm's authentication attribute or the delegated-credential bind path), the bind performed by context.getAttributes("", null) authenticates using the GSSAPI/Kerberos subject rather than the user's password. The missing critical step is that the GSSAPI SASL mechanism is never removed before the user-credential bind, so the bind can succeed without the supplied password ever being checked, while validated is still set to true. As a result, an attacker presenting a valid username with a wrong or empty password is authenticated.

Exploitation requires this specific, non-default configuration: a web application using JNDIRealm for authentication, with that realm configured for an authenticated bind using GSSAPI, and authentication flowing through the bind-validation path (no stored userPassword attribute). Default JNDIRealm configurations that do not use a GSSAPI authenticated bind are not affected.

‍

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.

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