The bouncer checks your face against the VIP list, but the door was already open from the service entrance nobody uses
CVE-2026-55957 is an authentication bypass in Apache Tomcat's JNDIRealm when configured to perform LDAP binds via GSSAPI (Kerberos). The bug is a missing critical step: when a user submits credentials, the realm validates them using the pre-configured Kerberos service principal instead of the user-supplied password, then marks the user as authenticated anyway. An attacker who knows a valid username can log in with any — or no — password. Affected versions span Tomcat 9.0.0.M1 through 9.0.100, with the fix landing in 9.0.101 (first GA release containing it: 9.0.102). The flaw also affects 11.0.0-M1–11.0.4, 10.1.0-M1–10.1.36, 8.5.0–8.5.100, and 7.0.0–7.0.109.
The vendor (Apache) rates this Important (their equivalent of HIGH), and Tenable's Nessus plugin 323710 flags it at CVSS 7.3 HIGH. However, this severity does not survive contact with reality. The vulnerability only fires when JNDIRealm is explicitly configured with GSSAPI as the bind authentication mechanism — a niche enterprise integration pattern used by a small minority of Tomcat deployments. The default Tomcat realm is UserDatabaseRealm backed by tomcat-users.xml; organizations using JDBC, DataSource, or even standard LDAP simple-bind JNDIRealm are unaffected. Tenable's own VPR score of 2.8 (Low) confirms their threat intelligence sees minimal real-world risk. The CVSS vector's C:L/I:L/A:L impact ratings further limit the blast radius even when exploitation succeeds. For the ~95%+ of Tomcat instances flagged by version-only detection that don't use this configuration, this is pure noise.
4 steps from start to impact.
Identify Tomcat with JNDIRealm + GSSAPI
GSSAPI authentication for LDAP binds. This requires either reconnaissance of the server.xml configuration (unlikely externally) or trial-and-error login attempts observing Kerberos-related error behavior. Banner grabbing alone does not reveal Realm configuration.- Target runs Tomcat 9.0.0.M1–9.0.100 (or equivalent in other branches)
- JNDIRealm is configured with authentication='GSSAPI' in server.xml
- The Tomcat login endpoint is network-reachable
- JNDIRealm + GSSAPI is a rare configuration — estimated <5% of Tomcat deployments
- Most Tomcat instances use UserDatabaseRealm, JDBCRealm, or simple-bind LDAP
- No external fingerprint distinguishes GSSAPI-configured JNDIRealm from other realms
Enumerate valid usernames
- Knowledge of at least one valid username in the backing LDAP/AD directory
- Applications behind JNDIRealm often use non-obvious internal usernames
- Rate limiting or account lockout policies may block enumeration
Submit credentials with wrong/empty password
HttpServletRequest.login()) with the valid username and any arbitrary password. Due to the bug, the JNDIRealm performs the LDAP bind using the pre-configured Kerberos GSSAPI subject instead of the supplied password, and incorrectly marks the authentication as successful. The attacker receives a valid session.- Steps 1 and 2 satisfied
- The application uses Tomcat's container-managed authentication (not a custom auth filter that bypasses Realm)
- Many modern Java apps implement authentication at the application layer (Spring Security, custom filters) and never invoke the Tomcat Realm at all
- Applications using OAuth2/OIDC, SAML, or JWT authentication are unaffected regardless of Realm config
Access application as authenticated user
- Successful authentication bypass from Step 3
- Application-layer authorization (role checks, RBAC) may further limit what the attacker can do
- Low CIA impact per CVSS — this is not full admin takeover in most cases
The supporting signals.
| In-the-Wild Exploitation | No evidence. Not listed in CISA KEV. No campaigns or threat actor usage reported as of 2026-09-21. |
|---|---|
| Proof-of-Concept | None public. No PoC repositories found on GitHub (checked nomi-sec/PoC-in-GitHub, SecureWithUmer/CVE-2026-PoCs). Exploitation is conceptually simple but requires the rare GSSAPI config to test against. |
| EPSS Score | 2.863% (86th percentile) — moderate exploitation probability, above average but not alarming. |
| CISA KEV Status | Not listed as of 2026-09-21. |
| CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L — 7.3 HIGH. Network-accessible, no auth needed, no user interaction, but all three CIA impacts are Low. The Low impacts are doing heavy lifting in keeping this at 7.3 rather than 9.8. |
| Affected Versions | Tomcat 9.0.0.M1–9.0.100, 10.1.0-M1–10.1.36, 11.0.0-M1–11.0.4, 8.5.0–8.5.100, 7.0.0–7.0.109. Only instances using JNDIRealm with authentication="GSSAPI" are actually exploitable. |
| Fixed Versions | 9.0.101 (first GA: 9.0.102), 10.1.37, 11.0.5. Distro backports: RHSA-2026:68659 (RHEL), check your distro tracker. Tomcat 8.5 and 7.0 are EOL — no official fix available. |
| Tenable VPR | 2.8 (Low) — Tenable's own threat-intel-adjusted score considers this low risk despite the 7.3 CVSS. This is a strong downward signal. |
| Exposure Footprint | ~100,000 internet-facing Tomcat instances per Shodan. CyCognito asset analysis: Consumer Discretionary 57.1%, Healthcare 16.0%, Materials 10.8% of observed affected instances. However, the subset running JNDIRealm+GSSAPI is a tiny fraction of this footprint. |
| Credit | Discovered by Ilan Toyter. Disclosed 2026-06-29 via Apache security mailing list. |
Why this verdict
- Configuration prerequisite eliminates ~95% of flagged hosts: JNDIRealm with GSSAPI authentication is a niche enterprise Kerberos/AD integration pattern. The default Tomcat Realm is UserDatabaseRealm. Most organizations use JDBC, DataSource, simple LDAP bind, or application-layer auth (Spring Security, OAuth2). Tenable plugin 323710 is version-only — it cannot distinguish vulnerable configurations from safe ones, making the majority of findings false positives.
- VPR 2.8 confirms low real-world risk: Tenable's own Vulnerability Priority Rating, which incorporates exploit maturity, threat actor activity, and age, scores this at 2.8/10 (Low). When even the vendor's threat intelligence says the CVSS is inflated, it's inflated.
- No PoC, no exploitation, no KEV: Zero public exploit code exists. No campaigns targeting this CVE have been observed. CISA has not added it to KEV. EPSS at 2.863% (86th percentile) is moderate but not high enough to override the configuration-gating friction.
- CIA impact is Low across the board: The CVSS vector explicitly rates C:L/I:L/A:L. Even successful exploitation yields limited access — partial data exposure, partial modification capability, not full application or system takeover.
- Role multiplier: Tomcat is a general-purpose application server, not a canonically high-value-role component. (a) *Low-value roles* (dev servers, test apps): auth bypass is inconsequential. (b) *Typical roles* (LOB web apps): auth bypass yields limited application access scoped to the impersonated user's privileges — blast radius is host-level at most. (c) *High-value roles*: Tomcat occasionally fronts sensitive apps (healthcare portals, financial dashboards), but the JNDIRealm+GSSAPI subset of *those* deployments is vanishingly small. Jenkins uses Tomcat but implements its own auth layer. No plausible chain from this CVE reaches domain takeover, fleet compromise, or supply-chain pivot. The HIGH floor does not apply because no realistic high-value-role scenario achieves fleet/domain-scale impact, and Tomcat is not canonically an identity, hypervisor, backup, or edge component.
Why not higher?
Upgrading to HIGH would require either active exploitation evidence, a public PoC lowering the bar for opportunistic attackers, or a plausible chain to domain/fleet-level impact. None of these conditions are met. The CVSS 7.3 already assumes the configuration prerequisite is satisfied — it does not discount for the rarity of that configuration in the real world. Tenable's own VPR of 2.8 is a strong market signal that HIGH overstates the operational risk.
Why not lower?
Dropping to LOW or IGNORE would undervalue the genuine risk to the minority of deployments that *do* run JNDIRealm with GSSAPI. For those hosts, this is a pre-authentication bypass reachable over the network with zero user interaction — a textbook critical-path vulnerability. The EPSS 86th percentile also sits above the threshold where we'd feel comfortable relegating this to backlog hygiene. MEDIUM correctly captures the conditional severity.
What to do — in priority order.
- Confirm your Realm configuration before patching — Run
grep -ri 'JNDIRealm' $CATALINA_BASE/conf/server.xmland check forauthentication="GSSAPI". If your Realm is UserDatabaseRealm, JDBCRealm, DataSourceRealm, or JNDIRealm with simple/DIGEST-MD5 bind, you are not vulnerable and can deprioritize. Do this immediately to triage your fleet. - Switch JNDIRealm to simple bind as interim mitigation — If you are using JNDIRealm with GSSAPI, change the authentication attribute to
simple(LDAP simple bind with a service account password) or switch to an application-layer auth mechanism. This eliminates the vulnerable code path without upgrading Tomcat. Validate LDAP connectivity after the change. Deploy within the noisgate 365-day remediation window (MEDIUM verdict — no mitigation SLA applies). - Upgrade to Tomcat 9.0.102+ — The definitive fix. Version 9.0.102 is the first generally available release containing the patch (commit
0cd21c0). For 10.x use 10.1.37+, for 11.x use 11.0.5+. Tomcat 8.5 and 7.0 are EOL — migrate to a supported branch. Target remediation within 365 days per noisgate remediation SLA for MEDIUM. - Deploy application-layer authentication — Modern Java applications should not rely solely on Tomcat container-managed authentication. Implement Spring Security, Apache Shiro, or an OAuth2/OIDC integration that validates credentials independently of the Tomcat Realm. This insulates you from all Realm-level vulnerabilities.
- WAF rules — The bypass uses legitimate login requests with valid usernames and normal HTTP form/BASIC auth headers. There is no malformed input or injection payload for a WAF to signature-match against.
- Network segmentation alone — If the Tomcat login page is reachable (even internally), the bypass works. Segmentation reduces attacker reachability but does not fix the authentication logic flaw.
- Upgrading Tomcat but keeping GSSAPI on EOL branches — Tomcat 8.5 and 7.0 will not receive a fix. If you're on these branches with JNDIRealm+GSSAPI, you must migrate, not just patch.
Crowdsourced verification payload.
Run this script on each Tomcat host as a user with read access to the Tomcat configuration directory (typically $CATALINA_BASE/conf/). Invoke: chmod +x check_cve_2026_55957.sh && ./check_cve_2026_55957.sh /opt/tomcat (pass your CATALINA_BASE path as the first argument). No root required unless conf files are root-only.
#!/usr/bin/env bash
# check_cve_2026_55957.sh — Detect CVE-2026-55957 (JNDIRealm GSSAPI auth bypass)
# Usage: ./check_cve_2026_55957.sh <CATALINA_BASE>
# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=UNKNOWN
set -euo pipefail
CATALINA_BASE="${1:-}"
if [[ -z "$CATALINA_BASE" ]]; then
echo "UNKNOWN — Usage: $0 <CATALINA_BASE>"
exit 2
fi
# --- Step 1: Determine Tomcat version ---
VERSION_FILE="$CATALINA_BASE/lib/catalina.jar"
if [[ ! -f "$VERSION_FILE" ]]; then
echo "UNKNOWN — Cannot find catalina.jar at $CATALINA_BASE/lib/"
exit 2
fi
VERSION=$(unzip -p "$VERSION_FILE" org/apache/catalina/util/ServerInfo.properties 2>/dev/null \
| grep '^server.number=' | cut -d'=' -f2 | tr -d '[:space:]')
if [[ -z "$VERSION" ]]; then
echo "UNKNOWN — Could not extract Tomcat version from catalina.jar"
exit 2
fi
echo "Detected Tomcat version: $VERSION"
# --- Step 2: Check if JNDIRealm with GSSAPI is configured ---
SERVER_XML="$CATALINA_BASE/conf/server.xml"
GSSAPI_CONFIGURED=false
if [[ -f "$SERVER_XML" ]]; then
if grep -qi 'JNDIRealm' "$SERVER_XML" && grep -qi 'GSSAPI' "$SERVER_XML"; then
GSSAPI_CONFIGURED=true
echo "WARNING: JNDIRealm with GSSAPI detected in server.xml"
else
echo "INFO: JNDIRealm with GSSAPI NOT found in server.xml"
fi
else
echo "WARNING: Cannot read $SERVER_XML — skipping config check"
fi
# --- Step 3: Version comparison for 9.x branch ---
# Vulnerable: 9.0.0 through 9.0.100 | Fixed: 9.0.101+
# Also check other branches
MAJOR=$(echo "$VERSION" | cut -d'.' -f1)
MINOR=$(echo "$VERSION" | cut -d'.' -f2)
PATCH=$(echo "$VERSION" | cut -d'.' -f3)
VULN_VERSION=false
case "$MAJOR" in
9)
if [[ "$PATCH" -le 100 ]]; then VULN_VERSION=true; fi
;;
10)
# 10.1.0-10.1.36 vulnerable
SUB=$(echo "$MINOR.$PATCH" | awk -F. '{print $2}')
if [[ "$MINOR" -eq 1 && "$PATCH" -le 36 ]]; then VULN_VERSION=true; fi
;;
11)
if [[ "$MINOR" -eq 0 && "$PATCH" -le 4 ]]; then VULN_VERSION=true; fi
;;
8)
if [[ "$MINOR" -eq 5 && "$PATCH" -le 100 ]]; then VULN_VERSION=true; fi
;;
7)
if [[ "$MINOR" -eq 0 && "$PATCH" -le 109 ]]; then VULN_VERSION=true; fi
;;
*)
echo "UNKNOWN — Unrecognized Tomcat major version: $MAJOR"
exit 2
;;
esac
# --- Step 4: Verdict ---
if $VULN_VERSION; then
if $GSSAPI_CONFIGURED; then
echo "VULNERABLE — Tomcat $VERSION with JNDIRealm+GSSAPI is exploitable (CVE-2026-55957)"
exit 1
else
echo "PATCHED (effectively) — Tomcat $VERSION is in the vulnerable range but JNDIRealm+GSSAPI is not configured. Version-only scanners will flag this; the host is not practically exploitable. Upgrade when convenient."
exit 0
fi
else
echo "PATCHED — Tomcat $VERSION is at or above the fixed version."
exit 0
fiWhat defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.