Apache Tomcat bypass in JNDIRealm: what IAM teams need to know

TL;DR: CVE-2026-55957 lets attackers bypass Apache Tomcat authentication when JNDIRealm uses GSSAPI binds, with a CVSS 9.8 score and affected releases spanning multiple supported and end-of-life branches, according to CYCOGNITO. The issue shows how directory-backed application identity can fail at the credential-validation layer, turning a configuration choice into an access-control collapse.

NHIMG editorial — based on content published by CYCOGNITO: Sample of assets impacted by Apache Tomcat Authentication Bypass, identified by the CyCognito Platform

By the numbers:

• CVE-2026-55957 carries a CVSS v3.1 base score of 9.8 for network access, low complexity, no privileges required, and no user interaction.
• Affected releases span Apache Tomcat 11.0.0-M1 through 11.0.4, 10.1.0-M1 through 10.1.36, 9.0.0.M1 through 9.0.100, 8.5.0 through 8.5.100, and 7.0.0 through 7.0.109.

Questions worth separating out

Q: What breaks when directory-backed application authentication is bypassed in Tomcat?

A: The application loses the trust boundary that normally separates unauthenticated traffic from protected internal functions.

Q: Why do directory-integrated applications increase IAM risk when authentication fails?

A: Because the application often treats the directory as the source of truth for both authentication and downstream authorisation.

Q: How can security teams know whether Tomcat authentication exposure is actually contained?

A: They should confirm every JNDIRealm deployment, verify whether GSSAPI binds are enabled, and check whether the vulnerable versions are still running in production, staging, or third-party hosted platforms.

Practitioner guidance

• Find every Tomcat instance using JNDIRealm with GSSAPI binds Build an estate-wide inventory of Java applications that delegate authentication to LDAP or Active Directory through JNDIRealm, then flag every instance where GSSAPI-authenticated binds are enabled.
• Map directory-backed access paths to protected business functions Identify which internal consoles, admin functions, and business workflows inherit access from the affected Realm.
• Restrict network reachability until upgrade is confirmed Limit access to affected Tomcat instances to trusted internal ranges, VPN segments, or reverse proxy paths while upgrade status is verified.

What's in the full analysis

CYCOGNITO's full article covers the operational detail this post intentionally leaves for the source:

• Affected version ranges and how to match them against your Tomcat estate
• Specific remediation guidance for supported and end-of-life Tomcat branches
• The exposure pattern observed across sectors and what that implies for inventory gaps
• Practical checks for third-party platforms that bundle their own Tomcat runtime

👉 Read CYCOGNITO's analysis of Apache Tomcat authentication bypass exposure →

Apache Tomcat bypass in JNDIRealm: what IAM teams need to know?

Explore further

View Full Forum →  |  NHI Foundation Course →