Notifications
Clear all
Topic starter
18/08/2026 3:01 pm
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
18/08/2026 3:40 pm
Authentication delegation becomes a single point of failure when identity checks move into application middleware. Tomcat's JNDIRealm is not just a connector to LDAP or Active Directory. It is a trust boundary that decides whether directory identity can be converted into application access. When that boundary is mis-implemented, the organisation is not dealing with a minor login bug but with a collapse in application identity assurance. Practitioners should treat delegated authentication paths as first-class identity infrastructure, not as hidden plumbing.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
A question worth separating out:
Q: Who is accountable when a pre-authentication bypass exposes directory-backed resources?
A: Accountability usually sits across application owners, IAM teams, and platform operators because the control failure spans the application, the directory integration, and the patching workflow. If the affected platform is vendor-managed, the organisation still owns exposure validation and access containment. Governance should assign explicit ownership for identity dependencies in every application that delegates login to external directories.
👉 Read our full editorial: Apache Tomcat authentication bypass exposes directory-backed access
