Apache Tomcat authentication bypass exposes directory-backed access

At a glance

What this is: This is a pre-authentication Apache Tomcat authentication bypass affecting JNDIRealm when GSSAPI-authenticated LDAP binds are configured.

Why it matters: It matters because directory-integrated application servers can expose high-value human and service access paths, and a single auth bypass can invalidate downstream IAM assumptions.

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.

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

Context

Apache Tomcat authentication bypass is a governance problem as much as a vulnerability problem because identity checks sitting inside application infrastructure are often assumed to be reliable once they are wired to a directory service. When the authentication boundary fails, every application behind it inherits that failure, including internal consoles, intranet systems, and legacy services that were never designed for hostile network exposure.

CVE-2026-55957 shows how a deployment-specific configuration can create a security blind spot: JNDIRealm with GSSAPI-authenticated binds delegates trust to external identity infrastructure, but it still has to validate credentials correctly. For IAM and PAM teams, the real issue is not just patching Tomcat, but understanding which applications depend on directory-backed access and whether those dependencies are tracked, monitored, and removable when control assumptions break.

These deployments are common in older enterprise environments and are often overlooked because they sit outside modern cloud-native visibility models. That makes the starting position described in the article unfortunately typical, not exceptional.

Key questions

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. When JNDIRealm accepts a bind without correctly verifying identity, the attacker can inherit the roles attached to that directory-backed account and reach whatever the application exposes behind it. In practice, that can mean admin functions, internal records, or other privileged workflows become reachable without legitimate login.

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. If the verification step fails, the resulting access can still look legitimate to the app. That creates a compounded IAM problem: one broken control can affect multiple systems that depend on the same identity assertion.

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. Containment is real only when the exposure is inventoried, the risky bind mode is removed or patched, and network reachability is narrowed to trusted paths.

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.

Technical breakdown

How JNDIRealm delegates authentication to directory services

JNDIRealm is Tomcat's bridge to external identity stores such as LDAP or Active Directory. Instead of validating a local application password, it asks the directory service to confirm the bind, then maps the resulting identity to application permissions. That design is efficient for centralised identity management, but it creates a hard dependency on the correctness of the bind flow and on the security of the directory integration path. If the validation step is flawed, the application trusts an identity signal that was never properly established.

Practical implication: inventory every application that depends on directory-backed authentication so a flaw in the auth bridge does not stay hidden.

Why GSSAPI bind handling creates a pre-authentication bypass path

GSSAPI is used for authenticated LDAP binds, often in Kerberos-backed enterprise environments. In this case, the flaw is a missing critical authentication step, which means the expected proof of identity is not enforced before access is granted. Because the issue occurs pre-authentication, an attacker does not need to steal a valid session first. The problem is not weak policy after login, but broken verification before login, which is a much more serious control failure in identity terms.

Practical implication: verify whether any Tomcat instance uses GSSAPI binds and treat that configuration as a priority exposure point until patched.

How directory-backed authorization amplifies the impact of a bypass

Once Tomcat accepts the attacker as authenticated, JNDIRealm passes through whatever access the directory-backed account would normally have. That means the practical blast radius is not limited to the authentication layer. It extends into internal resources, admin functions, and any data or actions protected by that Realm. This is a classic example of how authentication failures cascade into authorisation failures when identity is delegated across systems without strong containment and session-level validation.

Practical implication: map privilege attached to directory-backed application roles so a bypass cannot silently translate into broad application reach.

Threat narrative

Attacker objective: The attacker wants unauthorized access to applications and internal resources protected by the affected Tomcat Realm.

1. Entry occurs through a network-reachable Tomcat instance using JNDIRealm with GSSAPI-authenticated LDAP binds, allowing unauthenticated interaction with the vulnerable login flow.
2. Credential access is bypassed because the missing authentication step lets the attacker satisfy the Realm without supplying the correct password or valid proof of identity.
3. Impact follows as the attacker inherits the directory-backed permissions attached to that application identity and can reach protected resources without legitimate authentication.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Directory-backed application access creates an identity bridge that many organisations do not govern with the same discipline as human IAM. Internal apps often inherit credentials, roles, and access rules from corporate directories without the same lifecycle scrutiny applied to user accounts or privileged access. That is exactly where pre-authentication bypasses become dangerous, because the application may still expose high-value functions even when the directory trust chain is broken. The right control lens is access-path dependency, not only patch status.

Standing directory trust is a governance assumption that attackers can turn into immediate access. The flaw reveals a specific failure mode: organisations assume the directory will always be the authoritative gate, even when the application layer is the one enforcing the gate. That assumption breaks under a pre-authentication bypass, and the blast radius can include internal admin consoles, legacy line-of-business systems, and other protected interfaces. The practitioner conclusion is to identify where directory trust is acting as the sole control, then remove that single point of failure.

Configuration-specific exposure is still enterprise-wide risk when the affected pattern is common in legacy estates. The article makes clear that the flaw is narrowed by GSSAPI configuration, but that does not make it niche from a governance standpoint. Kerberos-backed LDAP and Active Directory integration are common in mature enterprises, especially for older Java platforms. Security teams should therefore treat this as a visibility problem as much as a vulnerability problem, because unknown directory-integrated instances are often the ones left exposed.

Application authentication bypasses should be evaluated through OWASP NHI and identity control frameworks, not only CVE triage. The issue is relevant to NHI governance because service-side authentication paths, directory integrations, and application credentials all participate in the trust chain. When a web tier can authenticate users incorrectly, the resulting risk is not confined to one app, but to every identity decision that app makes on behalf of users. That is why IAM, PAM, and application owners need a shared remediation view, not a siloed patch queue.

From our research:

• 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.
• That confidence gap is why organisations should pair application authentication reviews with identity lifecycle governance, as covered in Top 10 NHI Issues.

What this signals

Application authentication is becoming part of identity governance whether security teams planned for it or not. Tomcat-style directory delegation shows how application-layer identity decisions can bypass the visibility that IAM programmes rely on. Teams should therefore extend access review, control ownership, and dependency mapping into legacy middleware, not just cloud and SaaS identity stacks.

The practical signal is that hidden identity dependencies are now a material audit and resilience issue. When a web application can turn a directory bind into protected access, patching alone is not enough unless teams know where that trust path exists and who owns it. That is the programme change: build an inventory of delegated authentication paths, then validate them against a current control map.

For practitioners

• 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. Those are the systems where pre-authentication bypass risk exists and where patch verification should be immediate.
• Map directory-backed access paths to protected business functions Identify which internal consoles, admin functions, and business workflows inherit access from the affected Realm. If a bypass would expose more than a low-risk application, prioritise that system for containment, patching, and compensating controls.
• 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. This reduces the chance that a pre-authentication flaw can be probed from an exposed network edge.
• Disable GSSAPI binds where immediate upgrade is not possible If patching cannot be completed right away, remove the vulnerable bind mode rather than assuming the issue can be monitored around. That preserves directory service availability while eliminating the specific authentication path the flaw depends on.
• Validate third-party platforms that bundle Tomcat runtimes Check hosted applications, vendor appliances, and legacy platforms that ship their own Tomcat copy. These are often missed by central patch programs, yet they can still expose the same JNDIRealm authentication failure.

Key takeaways

• This vulnerability exposes a specific governance gap: organisations often trust delegated directory authentication without continuously validating the application layer that enforces it.
• The article's evidence shows a CVSS 9.8 pre-authentication bypass affecting multiple Tomcat branches, which makes exposure materially broader than a single isolated deployment.
• The control that matters most is inventory plus removal of the vulnerable bind path, because without it a directory-backed login can become an unauthorised access path.

Key terms

• JNDIRealm: JNDIRealm is Apache Tomcat's authentication component for delegating login checks to directory services such as LDAP or Active Directory. It translates directory-backed identity into application access, which makes the correctness of bind handling and role mapping central to the trust model.
• GSSAPI Bind: A GSSAPI bind is an authenticated LDAP connection method that usually relies on Kerberos-backed trust between client and directory service. In enterprise deployments it can simplify centralised authentication, but any flaw in bind validation can turn that trust path into an unauthorised access route.
• Pre-authentication Bypass: A pre-authentication bypass lets an attacker reach privileged functionality without first proving identity in the intended way. In practice, this means the control boundary fails before normal account checks, which is especially dangerous on appliances that govern traffic, certificates, or logging.
• Directory-backed Authentication: Directory-backed authentication is a login or access model that relies on a central directory such as Active Directory for identity checks and group membership decisions. When the directory is queried through vulnerable application code, the trust chain expands beyond the directory team and into the application layer.

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

👉 The full CYCOGNITO article covers affected versions, exposure patterns, and remediation guidance.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls across applications, platforms, and lifecycle processes.