Apache Tomcat Flaws Can Bypass Authentication and Default Servlet Security Rules

The Apache Software Foundation has disclosed two Apache Tomcat vulnerabilities that can weaken authentication and authorization controls in affected web applications.

The flaws are tracked as CVE-2026-55957 and CVE-2026-55956. The first affects JNDIRealm with GSSAPI authenticated bind, while the second affects default servlet security constraints.

Administrators should upgrade affected Tomcat 11, 10.1, and 9.0 deployments to the latest supported fixed releases. Unsupported Tomcat branches are also listed as affected in the CVE records, so teams still running them should move to a supported release line.

What Apache Fixed

CVE-2026-55957 is the more serious of the two issues. It can allow an attacker to authenticate without providing the correct password when Tomcat’s JNDIRealm is configured to authenticate binds using GSSAPI.

CVE-2026-55956 is a separate authorization issue. It occurs when security constraints are defined for the default servlet and Tomcat ignores configured HTTP methods or method omissions in those constraints.

Apache’s Tomcat 11 security page lists CVE-2026-55956 as fixed in Tomcat 11.0.23 and CVE-2026-55957 as fixed earlier in Tomcat 11.0.5.

CVE	Issue	Severity	Main condition	Primary impact
CVE-2026-55957	Missing critical authentication step	Important	JNDIRealm configured with GSSAPI authenticated bind	Authentication without the correct password
CVE-2026-55956	Improper authorization in default servlet constraints	Moderate	Security constraints applied to the default servlet	Method-based access restrictions ignored

CVE-2026-55957: JNDIRealm Authentication Bypass

CVE-2026-55957 affects Tomcat deployments using JNDIRealm with GSSAPI authenticated bind. In that configuration, Tomcat could miss a required authentication step and allow authentication without the correct password.

The NVD entry for CVE-2026-55957 lists affected versions as Tomcat 11.0.0-M1 through 11.0.4, 10.1.0-M1 through 10.1.36, and 9.0.0.M1 through 9.0.100. It also lists unsupported 8.5 and 7.0 versions as affected.

Apache fixed this issue in Tomcat 11.0.5, 10.1.37, and 9.0.101. Organizations running newer supported Tomcat releases may already have this fix, but they should still check for CVE-2026-55956 separately.

CVE-2026-55956: Default Servlet Security Constraints Ignored Methods

CVE-2026-55956 affects applications that define security constraints for Tomcat’s default servlet. When a constraint included an HTTP method or method omission, Tomcat could ignore that method-level rule.

The result is an authorization bypass risk. A resource that administrators expected to protect for one HTTP method could remain reachable because Tomcat did not enforce the method restriction as configured.

The Tomcat 10 security page says the issue was reported to the Tomcat security team on June 15, 2026, and made public on June 29, 2026.

• The issue applies only when security constraints are defined for the default servlet.
• The weak point is method-level handling inside those constraints.
• Configured methods and method omissions may not work as administrators intended.
• The impact depends on what the default servlet serves and how access rules are written.
• Apache lists no reliable mitigation that replaces upgrading.

Affected Tomcat Versions and Fixed Builds

The safest practical answer is to update to Tomcat 11.0.23, 10.1.56, or 9.0.119 or later, depending on the release line in use. Those builds include the CVE-2026-55956 fix and also include earlier fixes such as CVE-2026-55957.

The Tomcat 9 security page lists CVE-2026-55956 as affecting Tomcat 9.0.0.M1 through 9.0.118 and fixed in Tomcat 9.0.119.

Older unsupported Tomcat 8.5 and 7.0 branches appear in the CVE records for both issues. Since those branches no longer receive normal fixes, administrators should migrate away from them rather than looking for a backported vendor update.

Release line	CVE-2026-55957 affected range	CVE-2026-55956 affected range	Recommended fixed version
Tomcat 11	11.0.0-M1 through 11.0.4	11.0.0-M1 through 11.0.22	11.0.23 or later
Tomcat 10.1	10.1.0-M1 through 10.1.36	10.1.0-M1 through 10.1.55	10.1.56 or later
Tomcat 9.0	9.0.0.M1 through 9.0.100	9.0.0.M1 through 9.0.118	9.0.119 or later
Tomcat 8.5 and 7.0	Listed as affected	Listed as affected	Migrate to a supported branch

Why Method-Based Constraints Matter

Tomcat applications can use security constraints in web.xml to protect resources by URL pattern, role, transport requirement, and HTTP method. These rules often define which users can access sensitive files or application paths.

Method-level rules matter because applications sometimes allow one method and restrict another. For example, a site may allow GET for public downloads but restrict PUT, DELETE, or administrative methods to authenticated users.

If those method rules fail on the default servlet, the application may expose content or actions that administrators believed were protected. That risk grows when the default servlet handles sensitive static files, generated reports, upload directories, or WebDAV-style access patterns.

Who Faces The Highest Risk

The JNDIRealm issue mainly affects organizations that use LDAP-backed authentication through JNDIRealm with GSSAPI authenticated bind. Deployments that do not use that configuration should still patch, but they may not be exposed to CVE-2026-55957.

The default servlet issue has a broader configuration condition. It affects applications that define security constraints for the default servlet and rely on method-level access rules.

The CVE-2026-55956 record says the flaw leads to default servlet constraints ignoring any configured method or method omission, which can break intended access control.

Environment	Risk level	Reason
JNDIRealm with GSSAPI bind	High	Directly exposed to CVE-2026-55957 authentication bypass
Default servlet with method-based constraints	High	Directly exposed to CVE-2026-55956 authorization bypass
Internet-facing Tomcat apps	Medium to high	Attackers can probe exposed resources more easily
Internal-only apps	Medium	Compromised users or internal attackers may still exploit weak constraints
Unsupported Tomcat 8.5 or 7.0 deployments	High	No normal supported patch path for these branches

What Administrators Should Do Now

Administrators should inventory Tomcat servers first, then upgrade affected systems. The latest supported patch versions are the preferred target because they include both of these fixes and other recent Tomcat security updates.

Apache’s Tomcat 10.x security page notes that Tomcat 10.0.x has reached end of life and that users should upgrade to 10.1.x or later to receive security fixes.

After patching, teams should review authentication realms and web.xml security constraints. This matters because a configuration that looked correct before the update may finally behave as intended after the fix.

• Upgrade Tomcat 11 deployments to 11.0.23 or later.
• Upgrade Tomcat 10.1 deployments to 10.1.56 or later.
• Upgrade Tomcat 9.0 deployments to 9.0.119 or later.
• Migrate unsupported Tomcat 8.5 and 7.0 systems to supported branches.
• Identify any use of JNDIRealm with GSSAPI authenticated bind.
• Audit web.xml security constraints applied to the default servlet.
• Test protected resources with all relevant HTTP methods after upgrading.
• Review logs for unexpected access to protected static resources or sensitive paths.

No Workaround Replaces Upgrading

For these issues, configuration review helps identify exposure, but it should not replace installing fixed versions. The default servlet bug exists in Tomcat’s enforcement logic, so administrators should not assume that rewriting a rule fully removes risk.

Temporary exposure reduction can still help while teams schedule the update. For example, administrators can restrict public access to sensitive applications, disable unused methods at a reverse proxy, and move sensitive files outside directories served by the default servlet.

Those measures reduce risk but do not provide the same assurance as the patched Tomcat builds. Production systems should still receive the official update.

Why This Matters For Enterprise Tomcat Deployments

Tomcat often runs behind load balancers, reverse proxies, API gateways, and single sign-on systems. That layered setup can make teams assume the application server’s own security constraints are secondary.

That assumption creates risk. If a proxy rule changes, an internal route becomes reachable, or an application serves files directly through Tomcat, broken constraints can expose data or functionality that the application owner believed was protected.

The Apache Tomcat 11 advisory page shows that both issues were made public on June 29, 2026, which means security teams should expect scanners and proof-of-concept research to follow quickly.

How To Validate Fixes After Updating

After the upgrade, teams should test the actual access rules that matter to their applications. That means using the same roles, paths, and HTTP methods that the production application expects to control.

For CVE-2026-55957 exposure, teams should review JNDIRealm configuration and confirm that GSSAPI authenticated bind is used only where intended. For CVE-2026-55956, teams should test default servlet constraints using both allowed and denied methods.

The Tomcat 9 security page confirms that CVE-2026-55956 was reported on June 15 and made public on June 29, giving organizations a clear timeline for change management and patch verification.

Check	Why it matters	Priority
Tomcat version check	Confirms the patched build is actually running	Critical
JNDIRealm configuration review	Identifies exposure to the GSSAPI bind issue	High
Default servlet constraint testing	Confirms method-level restrictions work as intended	High
Reverse proxy method filtering	Reduces exposure to unexpected HTTP methods	Medium
Access log review	Looks for suspicious requests to protected resources	Medium

Bottom Line

The two Tomcat vulnerabilities affect different security layers. CVE-2026-55957 can weaken authentication in a specific JNDIRealm configuration, while CVE-2026-55956 can break method-based authorization rules for the default servlet.

Organizations should upgrade to Tomcat 11.0.23, 10.1.56, or 9.0.119 or later, depending on their release line. Teams on unsupported Tomcat branches should treat this as another reason to migrate to supported versions.

After patching, administrators should validate security constraints, authentication realm behavior, and HTTP method handling. The update fixes the platform bug, but application-level testing confirms that the intended access controls now work in production.

FAQ