What is CVE-2026-55957?
CVE-2026-55957 is a missing critical step in authentication in Apache Tomcat, present when the JNDIRealm is configured to authenticate binds using GSSAPI. The vulnerability carries a CVSS v3.1 base score of 9.8 (Critical), based on network attack vector, low attack complexity, no privileges required, and no user interaction. The Apache Tomcat security team classifies the issue as “Important,” a rating that reflects the deployment-specific nature of the affected configuration rather than the raw exploitability score.
Exploitation is pre-authentication. When JNDIRealm is set up to authenticate LDAP binds through GSSAPI, an attacker can authenticate without supplying the correct password, bypassing the credential check the Realm was designed to enforce. Because JNDIRealm is Tomcat’s mechanism for delegating authentication and authorization to an external directory server, a successful bypass grants the attacker whatever access that directory-backed identity carries inside the application.
The practical impact is unauthorized access to any resource protected by the affected Realm, with confidentiality and integrity exposure scaled to what the application exposes behind that authentication boundary. The condition that narrows exploitability is configuration-specific: JNDIRealm must be configured for GSSAPI-authenticated binds, a setup typically found in enterprise environments using Kerberos-backed LDAP or Active Directory integration.
What assets are affected by CVE-2026-55957?
The flaw sits in Tomcat’s JNDIRealm implementation and its handling of GSSAPI-authenticated LDAP binds. 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.
In practice, an affected asset is a Tomcat instance fronting a Java web application that delegates authentication to an LDAP or Active Directory server via JNDIRealm, with GSSAPI selected as the bind mechanism. This pattern is common in enterprise intranet applications, internal admin consoles, and legacy Java platforms that were wired into corporate directory services years before they became internet-facing.
These deployments tend to be overlooked precisely because they were built for internal use. Directory-integrated Tomcat instances are frequently exposed at the network edge through VPN gateways, reverse proxies, or forgotten firewall rules, long after the original access assumptions stopped holding.
What does our data show about exposure patterns?
Exposure in this set is led by Consumer Discretionary at 57.1% of observed assets, with Health Care contributing 16.0% and Materials contributing 10.8%.
Consumer Discretionary’s outsized share is consistent with how these organizations run technology. Retail, consumer services, and durables companies typically operate large, distributed networks of franchise systems, regional subsidiaries, and e-commerce platforms, each historically integrated with its own directory service for employee and partner access. That sprawl multiplies the number of JNDIRealm-backed Tomcat instances in play, and multiplies the odds that at least a few are internet-reachable and running an affected version.
The broader pattern across sectors points to a familiar risk driver: incomplete visibility into legacy authentication infrastructure. Directory-integrated application servers are set up once, rarely revisited, and easily missed by asset inventories that focus on newer cloud-native services. That gap between what security teams track and what is actually running is exactly where a vulnerability like this one persists undetected.
Are fixes available?
Yes. The Apache Software Foundation has released patched versions for all currently supported branches: Tomcat 11.0.5, 10.1.37, and 9.0.101.
Apache’s advisory lists no workaround other than upgrading, since the flaw is in the core bind-validation logic rather than in an optional feature that can be disabled. The 8.5.x and 7.0.x branches are past their end-of-life support windows, and organizations still running them should treat migration to a supported branch as part of the remediation, not an optional follow-up.
Defenders should verify their running version directly against the vendor advisory rather than assuming a fix is in place, particularly for instances managed by third parties or bundled inside application platforms that vendor their own Tomcat runtime.
Are there any other recommended actions to take?
Until patching is confirmed across all instances, defenders should:
- Inventory all Tomcat instances configured with JNDIRealm and GSSAPI binds
- Restrict network access to affected instances to trusted internal ranges only
- Monitor directory server logs for authentication attempts that bypass expected credential checks
- Audit recent access to directory-backed applications for anomalous or unauthorized sessions
- Disable GSSAPI-authenticated binds on JNDIRealm where an immediate upgrade is not feasible
- Confirm third-party platforms bundling Tomcat have shipped the corresponding fix
How can CyCognito help your organization?
CyCognito published an Emerging Threat Advisory for CVE-2026-55957 in the CyCognito platform and is actively researching enhanced detection capabilities for this vulnerability.
To learn how CyCognito can help your organization reduce external exposure and manage emerging threats more effectively, contact us to request a demo.
