CVE-2026-55957 · Apache Tomcat Authentication Bypass via JNDIRealm GSSAPI Bind

01 · The Real Story

The bouncer checks your face against the VIP list but never looks at the ticket you're holding

CVE-2026-55957 is an authentication bypass in Apache Tomcat's JNDIRealm component. When the realm is configured to authenticate LDAP binds using GSSAPI (Kerberos), the credential-validation path calls context.getAttributes which authenticates using the pre-configured GSSAPI/Kerberos service subject — not the password the user actually submitted. The realm then marks the user as successfully authenticated regardless of whether the supplied password was correct. An attacker who knows a valid username can log in with an empty or incorrect password and gain an authenticated session to whatever web application the realm protects. Affected versions span virtually the entire supported Tomcat tree: 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.

Apache rates this Important (HIGH, 7.3) but the CVSS vector's C:L/I:L/A:L impact metrics already telegraph that the vendor considers the blast radius limited — and correctly so. The critical gating factor is that only Tomcat instances with JNDIRealm explicitly configured for authentication="GSSAPI" are exploitable. This is not the default; it is a specialized enterprise setup for Kerberos/Active Directory SSO. Most Tomcat deployments use DataSourceRealm, UserDatabaseRealm, or JNDIRealm with simple LDAP bind. Shodan indexes ~120,000 internet-facing Tomcat instances, but the fraction running JNDIRealm+GSSAPI is vanishingly small — likely low single-digit percentages of all deployments. The vendor's HIGH rating is reasonable for shops that *do* run this config, but it overstates the risk for the general Tomcat population.

"Auth bypass is real but gated behind a niche GSSAPI config most shops never enable."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Identify Tomcat with JNDIRealm + GSSAPI

The attacker fingerprints a target as Apache Tomcat (trivial via HTTP headers, default error pages, or /manager paths). They then need to determine — or guess — that the target realm is JNDIRealm configured with GSSAPI binding. This is not externally observable; the attacker either has insider knowledge, is already inside the network, or is spraying login attempts against Tomcat instances hoping to hit the right config.

Conditions required:

Target runs an affected Tomcat version
JNDIRealm is configured with authentication=GSSAPI

Where this breaks in practice:

GSSAPI config is non-default and uncommon; most deployments use simple LDAP bind or other Realm types
No external banner or fingerprint reveals the authentication backend in use

Detection/coverage: Tomcat version fingerprinting is detectable via access logs; Qualys QID 87619 and Tenable plugin 205178 check Tomcat version ranges but do NOT confirm GSSAPI config

STEP 02

Enumerate valid usernames

The bypass requires a known valid username. The attacker probes the login form for username enumeration via timing or error-message differences, or uses usernames harvested from OSINT, LinkedIn, or prior breaches. In enterprises with JNDIRealm+GSSAPI, the usernames are typically Active Directory sAMAccountNames — predictable corporate formats like jsmith.

Conditions required:

Access to the Tomcat login form or API endpoint
At least one valid username in the backing LDAP/AD directory

Where this breaks in practice:

Well-configured apps return identical error messages for invalid user vs. wrong password
AD account lockout policies may trigger after enumeration attempts

Detection/coverage: Failed login events in Tomcat localhost_access_log and AD event ID 4625; SIEM correlation on repeated auth failures from single source IP

STEP 03

Submit login with arbitrary password

The attacker submits a login request (HttpServletRequest.login(username, anyPassword) or the equivalent form POST) with a valid username and any password — including an empty string. Due to CVE-2026-55957, the JNDIRealm's GSSAPI-configured bind path validates using the service keytab's subject, not the user-supplied password, and returns authentication success.

Conditions required:

Steps 1 and 2 satisfied
Network path to the Tomcat login endpoint

Where this breaks in practice:

If the Tomcat app is behind a WAF with credential-stuffing rules, rapid attempts may be blocked
MFA (if layered on top of Tomcat) would block exploitation at this step

Detection/coverage: The login succeeds, so no auth-failure log is generated — this is a silent bypass. Detection requires anomaly-based monitoring: unusual source IP, geolocation, or user-agent for the authenticated identity

STEP 04

Access protected application resources

With a valid authenticated session, the attacker accesses whatever the Tomcat-hosted web application exposes to the compromised identity. Impact is bounded by the application's authorization model — the attacker gets the permissions of the username they used, not admin privileges (unless they chose an admin username). This could include sensitive business data, internal tools, or management interfaces.

Conditions required:

Authenticated session obtained in Step 3

Where this breaks in practice:

Application-level RBAC may limit the attacker to low-privilege views if they chose a non-privileged username
Network segmentation may limit lateral movement from the Tomcat host

Detection/coverage: Application access logs showing the authenticated user accessing resources; UEBA flagging unusual access patterns for the compromised identity

03 · Compensating Control

MEDIUM 5.5→IGNORE 0.0

SEVERITY REDUCED

Disable GSSAPI binding in JNDIRealm and switch to simple LDAP bind — In server.xml, change the <Realm> element's authentication attribute from GSSAPI to simple (or remove it to use the default). This eliminates the vulnerable code path entirely. Use connectionName and connectionPassword for the service account bind instead. No noisgate mitigation SLA applies for MEDIUM — go straight to the 365-day remediation window, but this config change is low-risk and can be deployed immediately as a precaution.

MEDIUM 5.5→LOW 2.5

SEVERITY REDUCED

Layer MFA on Tomcat-hosted applications — Deploy MFA via a reverse proxy (e.g., Duo, Azure AD Application Proxy, or an OIDC gateway) in front of the Tomcat login form. Even if the password check is bypassed, the attacker cannot complete the second authentication factor. This is a defense-in-depth measure for any Tomcat app handling sensitive data.

MEDIUM 5.5→LOW 2.0

SEVERITY REDUCED

Restrict network access to the Tomcat login endpoint — Apply firewall rules or WAF policies to limit access to the Tomcat application's login paths to known corporate IP ranges, VPN egress, or Zero Trust network segments. This eliminates the AV:N component for external attackers.

MEDIUM 5.5→IGNORE 0.0

SEVERITY REDUCED

Upgrade Tomcat to patched versions — Apply the vendor patch: upgrade to 11.0.5, 10.1.37, or 9.0.101. For EOL branches (8.5, 7.0), migrate to a supported branch or obtain commercial backports. This is the definitive remediation. Per the noisgate remediation SLA for MEDIUM, complete within 365 days.

What doesn't work

WAF generic rules — the exploit is a normal HTTP login request with valid-looking credentials. No SQL injection, no path traversal, no payload signature. A WAF cannot distinguish a legitimate login from this bypass unless it has application-aware credential validation, which standard WAFs do not provide.
Tomcat Manager lockout — the vulnerability is in JNDIRealm, not the Tomcat Manager app. Disabling or restricting /manager does not affect applications using JNDIRealm for their own authentication.
Rotating the GSSAPI service keytab — the bug is in how the keytab subject is used during the bind; rotating it changes which Kerberos credentials are used but does not fix the logic flaw that skips password validation.

04 · Intelligence Metadata

The supporting signals.

In-the-Wild Exploitation	No known exploitation. Not listed on CISA KEV. No campaigns attributed to this CVE as of 2026-10-02. GreyNoise shows no observed scanning or exploitation activity.
Proof-of-Concept	No public PoC found. Checked pocindex.io, GitHub (no repos named CVE-2026-55957), ExploitDB, and Nuclei templates — all negative. Exploitation is conceptually simple (send a login request with any password) but requires the specific GSSAPI config to reproduce.
EPSS	0.02855 (2.86%) — indicates a low-to-moderate probability of exploitation within 30 days. Below the 85th percentile threshold that typically signals imminent weaponization.
CISA KEV	Not listed as of 2026-10-02. No federal remediation deadline applies.
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, low complexity, no auth required, but all three impact metrics are Low. The Low impacts accurately reflect that exploitation grants application-tier access, not system-level compromise.
Affected Versions	Tomcat 11.0.0-M1 – 11.0.4, 10.1.0-M1 – 10.1.36, 9.0.0-M1 – 9.0.100, 8.5.0 – 8.5.100, 7.0.0 – 7.0.109
Fixed Versions	11.0.5, 10.1.37, 9.0.101. Tomcat 8.5 and 7.0 are EOL; no official fix. HeroDevs offers backport 8.5.107 via NES. Distro backports: check RHSA-2026:68659, Amazon Linux ALAS-2026-55957.
Internet Exposure	Shodan indexes ~120,000 internet-facing Tomcat instances and ~177,000 Coyote JSP engine instances. However, the fraction running JNDIRealm with GSSAPI binding is estimated at <5% of all deployments — this is a specialized enterprise AD/Kerberos integration pattern.
Disclosure & Timeline	Disclosed 2026-06-29 via Apache security mailing list and oss-security. Fix commit `0cd21c0` landed in the Tomcat repo. Patch removes the GSSAPI authentication type from the JNDI context before credential validation and restores it afterward.
Reporter	Ilan Toyter — responsible disclosure to the Apache Tomcat security team.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to MEDIUM (5.5/10)

Why this verdict

Configuration prerequisite eliminates ~95% of the installed base. JNDIRealm with authentication="GSSAPI" is a non-default, specialized configuration for Kerberos/AD integration. Most Tomcat deployments use UserDatabaseRealm, DataSourceRealm, or JNDIRealm with simple LDAP bind. Only shops that deliberately wired Tomcat into Kerberos SSO are exposed — a low single-digit percentage of the ~120k internet-facing and millions of internal Tomcat instances.
No weaponization signals. No public PoC, no KEV listing, no in-the-wild exploitation, and EPSS of 2.86% places this well below the action threshold. The conceptual simplicity of the attack (send any password) is offset by the inability to remotely detect whether the target uses the vulnerable config, making mass exploitation impractical.
Impact is application-tier, not identity- or fleet-scale. The CVSS vector's C:L/I:L/A:L is accurate: the attacker gains the permissions of the username they spoofed within the web application's own authorization model. There is no privilege escalation to the OS, no lateral movement inherent to the vuln, and no domain-level impact.
Role multiplier: Tomcat is NOT a canonically high-value-role component. It is a general-purpose Java application server. In the high-value role catalog, it does not match identity providers, hypervisors, backup systems, CI/CD, PAM, or network edge appliances. When JNDIRealm+GSSAPI is configured, the Tomcat instance is typically fronting an enterprise intranet application — a typical (b) role. If the app happens to be a management console for infrastructure, the blast radius could reach host-tier, but this is deployment-specific and represents well under 1% of the affected installed base. The chain does NOT produce domain takeover, fleet compromise, or supply-chain impact in any standard deployment pattern. No floor applies.

Why not higher?

The attack is pre-auth and low complexity, which argues for HIGH. However, the mandatory GSSAPI configuration prerequisite is not an attacker-surmountable obstacle — it is a fixed property of the target that cannot be coerced or induced. This removes ~95% of the Tomcat installed base from the vulnerable population. Without exploitation in the wild, a public PoC, or KEV listing, the risk remains theoretical for the vast majority of defenders.

Why not lower?

When the GSSAPI config IS present, the bypass is trivially exploitable: network-accessible, no auth required, low complexity. The affected enterprises are typically large organizations running AD-integrated Java applications — environments where the data behind the login form tends to be sensitive. Dropping to LOW would understate the risk for the ~2-5% of deployments that are actually vulnerable.

06 · Verification

Crowdsourced verification payload.

Run this script on each Tomcat host as a user with read access to Tomcat's configuration files (typically tomcat or root). Invoke with the path to the Tomcat installation directory: sudo bash check_cve_2026_55957.sh /opt/tomcat. The script checks both the Tomcat version and the JNDIRealm GSSAPI configuration.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# check_cve_2026_55957.sh — Detect CVE-2026-55957 exposure
# Usage: bash check_cve_2026_55957.sh <CATALINA_HOME>
# Exit codes: 0=VULNERABLE, 1=PATCHED, 2=UNKNOWN

set -euo pipefail

CATALINA_HOME="${1:-}"
if [[ -z "$CATALINA_HOME" ]]; then
  echo "Usage: $0 <CATALINA_HOME>"
  exit 2
fi

# --- Detect Tomcat version ---
VERSION_FILE="$CATALINA_HOME/lib/catalina.jar"
if [[ ! -f "$VERSION_FILE" ]]; then
  echo "UNKNOWN — Cannot find catalina.jar at $CATALINA_HOME/lib/"
  exit 2
fi

TOMCAT_VER=$(unzip -p "$VERSION_FILE" org/apache/catalina/util/ServerInfo.properties 2>/dev/null \
  | grep '^server.number=' | cut -d= -f2 | tr -d '[:space:]')

if [[ -z "$TOMCAT_VER" ]]; then
  echo "UNKNOWN — Could not extract Tomcat version from catalina.jar"
  exit 2
fi

echo "Detected Tomcat version: $TOMCAT_VER"

# --- Check if version is in affected range ---
# Affected: 11.0.0-11.0.4, 10.1.0-10.1.36, 9.0.0-9.0.100, 8.5.0-8.5.100, 7.0.0-7.0.109
version_compare() {
  printf '%s\n%s' "$1" "$2" | sort -V | head -n1
}

VULN_VERSION=false
MAJOR=$(echo "$TOMCAT_VER" | cut -d. -f1)
MINOR=$(echo "$TOMCAT_VER" | cut -d. -f2)
PATCH=$(echo "$TOMCAT_VER" | cut -d. -f3)

case "$MAJOR" in
  11) [[ $(version_compare "$TOMCAT_VER" "11.0.4") == "$TOMCAT_VER" || "$TOMCAT_VER" == "11.0.4" ]] && \
      [[ $(version_compare "11.0.0" "$TOMCAT_VER") == "11.0.0" || "$TOMCAT_VER" == "11.0.0" ]] && \
      VULN_VERSION=true ;;
  10) [[ "$MINOR" -eq 1 ]] && \
      [[ $(version_compare "$TOMCAT_VER" "10.1.36") == "$TOMCAT_VER" || "$TOMCAT_VER" == "10.1.36" ]] && \
      VULN_VERSION=true ;;
  9)  [[ $(version_compare "$TOMCAT_VER" "9.0.100") == "$TOMCAT_VER" || "$TOMCAT_VER" == "9.0.100" ]] && \
      VULN_VERSION=true ;;
  8)  [[ "$MINOR" -eq 5 ]] && \
      [[ $(version_compare "$TOMCAT_VER" "8.5.100") == "$TOMCAT_VER" || "$TOMCAT_VER" == "8.5.100" ]] && \
      VULN_VERSION=true ;;
  7)  [[ $(version_compare "$TOMCAT_VER" "7.0.109") == "$TOMCAT_VER" || "$TOMCAT_VER" == "7.0.109" ]] && \
      VULN_VERSION=true ;;
esac

if [[ "$VULN_VERSION" == false ]]; then
  echo "PATCHED — Tomcat $TOMCAT_VER is not in the affected version range."
  exit 1
fi

echo "Version $TOMCAT_VER is in the affected range."

# --- Check for JNDIRealm with GSSAPI configuration ---
GSSAPI_FOUND=false
CONFIG_FILES=$(find "$CATALINA_HOME/conf" -name '*.xml' -type f 2>/dev/null)

for cfg in $CONFIG_FILES; do
  if grep -qi 'JNDIRealm' "$cfg" 2>/dev/null; then
    if grep -qi 'GSSAPI' "$cfg" 2>/dev/null; then
      GSSAPI_FOUND=true
      echo "GSSAPI JNDIRealm config found in: $cfg"
      break
    fi
  fi
done

if [[ "$GSSAPI_FOUND" == true ]]; then
  echo "VULNERABLE — Tomcat $TOMCAT_VER with JNDIRealm GSSAPI configuration detected."
  echo "Remediation: Upgrade to 11.0.5, 10.1.37, or 9.0.101, or disable GSSAPI binding."
  exit 0
else
  echo "PATCHED — Tomcat $TOMCAT_VER is in the affected version range but JNDIRealm with GSSAPI is NOT configured."
  echo "This instance is not exploitable for CVE-2026-55957."
  exit 1
fi