The Apache Tomcat security team publicly disclosed two authentication and access control bypass vulnerabilities on June 29, 2026. The more severe, CVE-2026-55957, allows an attacker to authenticate to a Tomcat application without providing the correct password when JNDIRealm is configured with a GSSAPI authenticated bind — a common enterprise configuration for Kerberos/Active Directory integration. CVE-2026-55956, a related moderate-severity issue, allows attackers to bypass HTTP method-based security constraints configured on the default servlet.

Neither vulnerability requires authentication to exploit by definition — both circumvent the authentication or authorization check entirely. CVE-2026-55957 affects Tomcat 9.x through 9.0.100, 10.1.x through 10.1.36, and 11.x through 11.0.4. Fixes are available in Tomcat 9.0.101, 10.1.37, and 11.0.5.

Tomcat is among the most widely deployed Java application servers, running behind millions of web applications, internal enterprise portals, and internet-facing services. Organizations using JNDIRealm with GSSAPI for Active Directory or Kerberos authentication integration should treat this as an urgent patch.

What the Vulnerabilities Are

CVE-2026-55957 — JNDIRealm GSSAPI Authentication Bypass (Important)

Apache Tomcat's JNDIRealm is a standard authentication component that validates user credentials against an LDAP/Active Directory server via the Java Naming and Directory Interface (JNDI). When JNDIRealm is configured to use GSSAPI (Generic Security Services API) for authenticated bind operations — the mechanism used to integrate Tomcat with Kerberos or Windows Active Directory Integrated Authentication — a flaw in the authentication logic allows an attacker to bypass credential validation entirely.

In a correctly functioning JNDIRealm with GSSAPI bind, Tomcat uses the Kerberos/GSSAPI token to authenticate the LDAP bind, then verifies the user's password against the directory. Due to CVE-2026-55957, this verification step is bypassed when GSSAPI is in use: an attacker can supply any password (or no password) and still receive a valid authenticated session.

The result is that any user account known to exist in the LDAP/AD directory can be impersonated without knowledge of their password. In environments where Tomcat is used as the authentication gateway for business applications, this means complete access to those applications for any valid account name.

The issue was reported to the Tomcat security team on June 14, 2026 by Ilan Toyter, and made public on June 29, 2026.

Affected versions: Tomcat 9.0.0-M1 through 9.0.100, 10.1.0-M1 through 10.1.36, 11.0.0-M1 through 11.0.4
Fixed versions: 9.0.101, 10.1.37, 11.0.5

CVE-2026-55956 — Default Servlet HTTP Method Security Constraint Bypass (Moderate)

CVE-2026-55956 is a separate issue in how Tomcat enforces HTTP method-based access controls. When security constraints are configured on the default servlet specifying which HTTP methods are permitted or denied, Tomcat fails to enforce those constraints correctly — requests using methods that should be blocked are permitted through.

This allows bypassing application-level security policies defined in web.xml or through Tomcat's security constraint configuration. While rated Moderate and requiring a specific non-default configuration, any deployment that uses HTTP method restrictions as part of its access control model is affected.

Reported by j0hndo. Affects a broader range of Tomcat versions than CVE-2026-55957.

Affected versions: Tomcat 9.0.0-M1 through 9.0.118, 10.1.0-M1 through 10.1.55, 11.0.0-M1 through 11.0.22
Fixed versions: 9.0.119, 10.1.56, 11.0.23

Why It Matters

GSSAPI/Kerberos integration is common in enterprise Tomcat deployments. Organizations using Active Directory for single sign-on often configure Tomcat's JNDIRealm with GSSAPI to enable seamless domain authentication. This is the configuration that triggers CVE-2026-55957. If you integrated Tomcat with AD or Kerberos for SSO, you are in the affected population.

Authentication bypass enables full application access, not just reconnaissance. An attacker exploiting CVE-2026-55957 does not see a degraded, limited session — they receive a fully authenticated session as any user they name. For applications managing HR data, financial records, internal tools, or sensitive business logic, this grants complete access to everything that user could see or do.

Account enumeration is the only prerequisite. Exploiting CVE-2026-55957 requires knowing a valid username in the LDAP/AD directory. In most enterprise environments, usernames are easy to enumerate: email addresses, LinkedIn profiles, corporate directories, or LDAP anonymous bind (if enabled) all expose username formats. The attacker does not need to know any password.

CVE-2026-55956 undermines defense-in-depth configurations. Many development teams use HTTP method restrictions to prevent unintended write operations — blocking PUT, DELETE, or TRACE at the Tomcat layer as a secondary control behind application logic. If CVE-2026-55956 bypasses this, any application relying on those restrictions as a security control is exposed.

Tomcat's large installed base makes this high-value for automated exploitation. Shodan and Censys routinely index hundreds of thousands of Tomcat instances. A working exploit for CVE-2026-55957 would be trivially deployable at scale by any threat actor, since the only variable is the target URL and a valid username — both obtainable without credentials.

Am I Affected?

For CVE-2026-55957, you are affected if:

  1. You run Apache Tomcat 9.0.x (up to and including 9.0.100), 10.1.x (up to and including 10.1.36), or 11.0.x (up to and including 11.0.4)
  2. AND you have JNDIRealm configured in server.xml or a context configuration file
  3. AND JNDIRealm is configured with connectionName using a GSSAPI-authenticated bind (i.e., the bind credential uses Kerberos rather than a simple bind DN + password)

To check JNDIRealm configuration, look in your $CATALINA_HOME/conf/server.xml or application-level context.xml for entries like:

<Realm className="org.apache.catalina.realm.JNDIRealm"
       connectionURL="ldap://your-ad-server:389"
       ...
       authentication="GSSAPI"
       .../>

If authentication="GSSAPI" (or equivalent userRoleAttribute patterns indicating GSSAPI) is present and your Tomcat version falls in the affected range, you are vulnerable.

For CVE-2026-55956, you are affected if:

  1. You run Tomcat 9.0.0-M1 through 9.0.118, 10.1.0-M1 through 10.1.55, or 11.0.0-M1 through 11.0.22
  2. AND you have <security-constraint> elements in your web.xml that specify <http-method> or <http-method-omission> restrictions on the default servlet

To check your Tomcat version:

$CATALINA_HOME/bin/version.sh
# or on Windows:
%CATALINA_HOME%\bin\version.bat

What to Do About It: Step-by-Step

Step 1: Upgrade Tomcat to a fixed version.

Download the appropriate fixed release from the Apache Tomcat download pages for 9.x, 10.1.x, or 11.x:

  • Tomcat 9.x → upgrade to 9.0.101 or later (for CVE-2026-55957); 9.0.119 or later also addresses CVE-2026-55956
  • Tomcat 10.1.x → upgrade to 10.1.37 or later (CVE-2026-55957); 10.1.56 or later for CVE-2026-55956
  • Tomcat 11.x → upgrade to 11.0.5 or later (CVE-2026-55957); 11.0.23 or later for CVE-2026-55956

If you manage Tomcat via a distribution package (Red Hat, Debian, Ubuntu, Amazon Linux), check whether your distribution has released updated packages and prefer the distribution's package over a manual upgrade if you use package-managed deployments.

Step 2: If immediate upgrade is not feasible, assess your JNDIRealm configuration.

If you cannot upgrade immediately, verify whether your JNDIRealm deployment uses GSSAPI. If it does not use GSSAPI authentication (most JNDIRealm deployments use simple bind with a service account DN and password), you are not vulnerable to CVE-2026-55957 and can defer the upgrade while scheduling it.

If GSSAPI is in use, consider switching JNDIRealm to simple bind as a temporary mitigation while the upgrade is planned. This changes the authentication mechanism but removes the vulnerable GSSAPI code path. Consult your directory team before making this change as it affects the Kerberos/SSO integration.

Step 3: Review application access logs for authentication patterns consistent with exploitation.

In Tomcat's access logs (typically $CATALINA_HOME/logs/access_log.*), look for successful authenticated requests from unusual source IPs, or requests that authenticated successfully as accounts that do not normally access your application. Particular attention should be paid to authentication success for accounts belonging to administrators or privileged service accounts.

Enable Tomcat's JNDIRealm debug logging temporarily (org.apache.catalina.realm.JNDIRealm at DEBUG in conf/logging.properties) to get detailed authentication event records during the investigation window.

Step 4: Restart Tomcat after upgrading to confirm the new version is running.

After upgrading, verify the running version with:

curl -s http://localhost:8080/ | grep -i "Apache Tomcat"
# or check the startup log:
grep "Server version" $CATALINA_HOME/logs/catalina.out | tail -3

Confirm it reports the upgraded version number.

Quick-Win Checklist

  • Identified Tomcat version on all instances in your environment
  • Checked JNDIRealm configuration for GSSAPI authentication bind (CVE-2026-55957 precondition)
  • Upgraded to Tomcat 9.0.101 / 10.1.37 / 11.0.5 (CVE-2026-55957 fix) on affected instances
  • Upgraded to Tomcat 9.0.119 / 10.1.56 / 11.0.23 if relying on HTTP method security constraints (CVE-2026-55956 fix)
  • Verified the upgraded version is running via startup logs or version endpoint
  • Reviewed Tomcat access logs for unexpected successful authentication events from unusual IPs or accounts

Sources