Missing Critical Step in Authentication vulnerability in Apache Tomcat when the JNDIRealm was configured to…

Apache Tomcat's JNDIRealm is the plumbing that lets a webapp defer authentication to an LDAP directory. When configured for GSSAPI authenticated bind (Kerberos-based service account binding to LDAP), the realm accepts a user as authenticated even when the supplied password is wrong — the critical *did the bind actually succeed with the user's credentials* check was missing. Any attacker who can reach the Tomcat auth endpoint and knows (or guesses) a valid username walks in as that user. Affected: 11.0.0-M1 → 11.0.4, 10.1.0-M1 → 10.1.36, 9.0.0-M1 → 9.0.100, and legacy 8.5.0 → 8.5.100 / 7.0.0 → 7.0.109. Fixed in 11.0.5, 10.1.37, 9.0.101.

Vendor called this Important / HIGH (7.3). That rating assumes the vulnerable configuration is in play. In reality, JNDIRealm with authentication="GSSAPI" on the connection user is a *minority* configuration — most Tomcat deployments either use no realm, use a simpler LDAP simple-bind, or front auth with SSO/reverse proxy. For the fraction that *is* configured this way, HIGH is fair; for the fleet at large, MEDIUM better reflects the exposure population.

Why this verdict

• Config-gated, not code-gated: the vulnerability requires an opt-in realm configuration (authentication="GSSAPI" on JNDIRealm). Default and most-common Tomcat deployments never touch this code path.
• Username-only bypass, not full compromise: the attacker still needs a valid directory username, and the resulting privilege is capped at that user's assigned roles — CVSS shows only *partial* C/I/A, not the full-impact profile of a typical HIGH.
• Role multiplier — enterprise SSO gateway: where a Tomcat instance IS the auth broker for a downstream app on an intranet (portal, HR, finance webapp), the chain ends in impersonation of arbitrary users including admins → role floor is HIGH for that subset. But this role represents well under 10% of the installed base, so the overall verdict floor is MEDIUM, not CRITICAL.
• Role multiplier — public-facing webapps: typical (b) role. Impact is one-user-at-a-time impersonation; not fleet-scale.
• No KEV, low EPSS, no PoC in the wild: exploitation probability is quantitatively low; attacker interest lags disclosure.
• Silent to LDAP-side monitoring: the bypass avoids the LDAP bind entirely, so directory audit logs won't catch it — a real *detection* penalty that keeps this above LOW.

Why not higher?

HIGH would require the vulnerable configuration to be the norm, or the bypass to yield unbounded privilege. Neither holds: JNDIRealm+GSSAPI is a minority pattern, and the attacker inherits only the impersonated user's roles. No KEV listing, no active exploitation, and no public weaponized PoC further pull it off HIGH.

Why not lower?

LOW/IGNORE is wrong because for the shops that *do* run this config — typically enterprises with Kerberos-backed AD auth — the bypass is unauthenticated and requires only a valid username, which is trivial to obtain. The blast radius in enterprise portals (admin impersonation) is non-trivial, and LDAP-side detection is blind to the bypass.

1. Inventory JNDIRealm+GSSAPI usage across the Tomcat fleet — Grep every server.xml, context.xml, and per-app context config for JNDIRealm with authentication="GSSAPI" or connectionURL referencing a KDC. Hosts without this config are NOT vulnerable and should be deprioritized. Complete inventory within 7 days so the 365-day remediation window is scoped correctly.
2. Switch vulnerable realms to simple-bind or reverse-proxy SSO — If you can tolerate it, reconfigure JNDIRealm to use authentication="simple" with proper credentials, or better, offload auth to a reverse-proxy SSO (nginx+OIDC, mod_auth_openidc, Kong, oauth2-proxy) that pre-authenticates before Tomcat sees the request. This kills the code path entirely. No mitigation SLA at MEDIUM — go straight to the 365-day remediation window, but do this before then if you can.
3. Front Tomcat with mTLS or IP allowlist while patching — For internet-exposed Tomcat, put a WAF/reverse proxy in front that requires client certs or restricts to known corporate IPs. This shrinks the attackable population to insiders while you plan the upgrade.
4. Correlate Tomcat access logs against LDAP bind logs — A successful Tomcat auth event with no corresponding LDAP bind is the bypass fingerprint. Build a SIEM rule that joins Tomcat access logs (200 on protected paths with Authorization: Basic) against your directory's bind audit — mismatches are your alert.

Run this on each Tomcat host as a user that can read $CATALINA_HOME (usually the tomcat service account or root). Invoke as ./check-cve-2026-55957.sh /opt/tomcat — argument is the Tomcat install directory. It checks the version string AND greps for the vulnerable JNDIRealm+GSSAPI configuration; a host is only truly vulnerable if BOTH are true.

#!/usr/bin/env bash
# check-cve-2026-55957.sh — Apache Tomcat JNDIRealm GSSAPI auth bypass
# Usage: ./check-cve-2026-55957.sh /path/to/tomcat
set -u
CATALINA_HOME="${1:-/opt/tomcat}"

if [[ ! -d "$CATALINA_HOME" ]]; then
  echo "UNKNOWN: $CATALINA_HOME not found"
  exit 2
fi

# 1. Version detection
VER_RAW="$("$CATALINA_HOME/bin/version.sh" 2>/dev/null | grep -E 'Server number' | awk '{print $NF}')"
if [[ -z "$VER_RAW" ]]; then
  VER_RAW="$(find "$CATALINA_HOME/lib" -name 'catalina.jar' -exec unzip -p {} META-INF/MANIFEST.MF \; 2>/dev/null | awk -F': ' '/Implementation-Version/ {print $2}' | tr -d '\r')"
fi

if [[ -z "$VER_RAW" ]]; then
  echo "UNKNOWN: could not determine Tomcat version"
  exit 2
fi

VER_VULN=0
IFS='.' read -r MAJ MIN PATCH <<< "$VER_RAW"
case "$MAJ" in
  11) [[ "$MIN" -eq 0 && "$PATCH" -lt 5   ]] && VER_VULN=1 ;;
  10) [[ "$MIN" -eq 1 && "$PATCH" -lt 37  ]] && VER_VULN=1 ;;
  9)  [[ "$MIN" -eq 0 && "$PATCH" -lt 101 ]] && VER_VULN=1 ;;
  8)  [[ "$MIN" -eq 5 ]] && VER_VULN=1 ;;
  7)  VER_VULN=1 ;;
esac

# 2. Config detection: JNDIRealm with authentication="GSSAPI"
CFG_VULN=0
MATCHES="$(grep -riIlE 'JNDIRealm' "$CATALINA_HOME/conf" "$CATALINA_HOME/webapps" 2>/dev/null || true)"
for f in $MATCHES; do
  if grep -qE 'authentication[[:space:]]*=[[:space:]]*"GSSAPI"' "$f"; then
    CFG_VULN=1
    echo "  vulnerable config in: $f"
  fi
done

echo "Tomcat version: $VER_RAW  (version-vulnerable=$VER_VULN)"
echo "JNDIRealm+GSSAPI configured: $CFG_VULN"

if [[ $VER_VULN -eq 1 && $CFG_VULN -eq 1 ]]; then
  echo "VULNERABLE"
  exit 1
elif [[ $VER_VULN -eq 1 && $CFG_VULN -eq 0 ]]; then
  echo "PATCHED (version vulnerable but config not present — not exploitable)"
  exit 0
else
  echo "PATCHED"
  exit 0
fi

Sources

1. Apache Tomcat 11 security advisories
2. Apache Tomcat 10 security advisories
3. Apache Tomcat 9 security advisories
4. Tenable Nessus plugin 323709 — Tomcat 11 vulnerability check
5. CyberSecurityNews — Multiple Apache Tomcat auth bypass CVEs
6. GBHackers — Tomcat vulnerabilities let attackers bypass authentication
7. HeroDevs — Apache Tomcat CVE round-up April 2026
8. Cryptika — Apache Tomcat auth bypass writeup