CVE-2026-101296 · Apache Tomcat JNDIRealm authentication bypass via non-GSSAPI SASL…

01 · The Real Story

The front door's deadbolt looks locked, but the latch spring is broken — anyone who turns the handle walks right in

CVE-2026-101296 is an authentication bypass in Apache Tomcat's JNDIRealm component. When JNDIRealm is configured to authenticate users against an LDAP directory using a non-GSSAPI SASL mechanism (e.g., DIGEST-MD5, CRAM-MD5), a missing validation step in the SASL bind flow causes the credential check to *fail open*. An unauthenticated, remote attacker can supply any password — or no password at all — and the realm will accept the bind as successful. The flaw affects every supported branch: Tomcat 11.0.0-M1 through 11.0.26, 10.1.0-M1 through 10.1.60, 9.0.0.M1 through 9.0.122, plus EOL branches 8.5.x and 7.x. The fix forces the realm to override whatever SASL mechanism is configured and use SECURITY_AUTHENTICATION = "simple" (LDAP simple bind) when binding as the user, then restores the original mechanism afterward.

Apache rated this Important — their second-highest tier — but declined to publish a CVSS score. A third-party CVSS v4.0 assessment came in at 9.1 Critical (AT:P captures the configuration prerequisite). That 9.1 overstates fleet-wide risk because JNDIRealm with a non-GSSAPI SASL mechanism is a rare configuration: Tomcat ships with no realm configured by default, most deployments use DataSourceRealm, UserDatabaseRealm, or simple-bind JNDIRealm. DIGEST-MD5 was moved to Historic status by RFC 6331 years ago, and CRAM-MD5 is almost never used for LDAP. The realistic vulnerable population is a sliver — but for that sliver, the impact is a complete, zero-click authentication bypass over the network. noisgate assesses this at HIGH 7.5, acknowledging both the severity of the mechanism and the narrow blast radius.

"Full auth bypass on Tomcat JNDIRealm with non-GSSAPI SASL — deadly if you use it, irrelevant if you don't"

02 · The Attack Path

5 steps from start to impact.

STEP 01

Discover Tomcat login surface

The attacker identifies a Tomcat-hosted application that requires authentication. This can be an internet-facing portal, an internal enterprise web app behind a VPN, or the Tomcat Manager console itself. Discovery is trivial via Shodan (Server: Apache-Coyote), HTTP response headers, or default error pages. Over 300,000 Tomcat instances are indexed on Shodan globally.

Conditions required:

Network access to the Tomcat HTTP/HTTPS port (typically 8080/8443)

Where this breaks in practice:

Many Tomcat login pages are behind VPN, WAF, or not directly internet-facing
Tomcat Manager is often restricted to localhost by default via RemoteAddrValve

Detection/coverage: Shodan, Censys, and FOFA index Tomcat instances. Qualys QID and Tenable plugins for version detection exist. No dedicated CVE-2026-101296 scanner plugin yet (2 days post-disclosure).

STEP 02

Identify JNDIRealm with non-GSSAPI SASL

The attacker needs the target's Tomcat instance to be configured with JNDIRealm using a non-GSSAPI SASL mechanism (DIGEST-MD5, CRAM-MD5, or similar). This is not detectable externally — there is no HTTP header or response that leaks the realm type or SASL mechanism. The attacker either has prior knowledge (e.g., from source code, config leaks, or insider information) or simply attempts the bypass blind.

Conditions required:

Target Tomcat must have <Realm className="org.apache.catalina.realm.JNDIRealm" ... authentication="DIGEST-MD5"/> or equivalent non-GSSAPI SASL in server.xml or context.xml

Where this breaks in practice:

JNDIRealm with non-GSSAPI SASL is a rare, non-default configuration
Most LDAP-backed Tomcat instances use simple bind (the default), which is not affected
DIGEST-MD5 has been deprecated since RFC 6331 (2011); new deployments almost never choose it

Detection/coverage: Internal config audits or SAST scanning of server.xml/context.xml for JNDIRealm + authentication attribute values. No external detection method.

STEP 03

Submit authentication with arbitrary credentials

The attacker sends a standard HTTP login request (form POST, BASIC auth header, or DIGEST challenge-response depending on the app's authenticator valve) with a valid username and any password. The username must exist in the LDAP directory — but the password can be anything, including empty. No special tooling is required; curl, a browser, or Burp Suite suffices.

Conditions required:

A valid username in the LDAP directory (can be guessed or enumerated via other means)
The target application's login form or HTTP auth challenge is reachable

Where this breaks in practice:

Username enumeration may be needed if the attacker doesn't already know a valid account
Some applications present CAPTCHA or lockout after failed attempts, though the *first* attempt already succeeds

Detection/coverage: Failed login monitoring is ineffective here because the login succeeds. Anomaly detection on source IP or unusual login times is the best bet.

STEP 04

SASL bind fails open — credential check skipped

Internally, JNDIRealm.bindAsUser() attempts to bind to the LDAP directory as the submitted user. Because the authentication environment property is set to the non-GSSAPI SASL mechanism (e.g., DIGEST-MD5), the JNDI LDAP provider initiates a SASL negotiation. The bug: Tomcat's code does not override this to simple before the user bind, and the SASL result is not properly validated. The bind completes without actually verifying the user's password against the directory. The realm returns authenticated = true.

Conditions required:

The vulnerable code path in JNDIRealm.java is executed (guaranteed on affected versions with the config)

Where this breaks in practice:

None once steps 1-3 are satisfied — this is the core bug

Detection/coverage: LDAP server logs may show a SASL bind attempt followed by success without proper credential exchange, but most organizations do not alert on successful LDAP binds.

STEP 05

Authenticated session — access protected resources

With authentication bypassed, the attacker receives a valid session cookie and gains access to whatever the Tomcat application protects. This could be business data, admin panels, API endpoints, or — in the worst case — the Tomcat Manager application, which allows WAR file deployment and thus remote code execution on the server. The blast radius depends entirely on what sits behind the login.

Conditions required:

Authenticated session is granted (guaranteed after step 4)

Where this breaks in practice:

Tomcat Manager access is typically restricted by RemoteAddrValve to 127.0.0.1, limiting RCE escalation
Most JNDIRealm deployments protect line-of-business apps, not Manager

Detection/coverage: Application access logs will show successful authentication from the attacker's IP. SIEM correlation of new source IPs accessing sensitive endpoints post-login.

03 · Compensating Control

HIGH 7.5→IGNORE 0.0

SEVERITY REDUCED

Switch JNDIRealm authentication to simple bind immediately — Edit server.xml or context.xml and either remove the authentication attribute from the <Realm className="...JNDIRealm" .../> element (simple bind is the default) or explicitly set authentication="simple". Simple bind is unaffected by this CVE. This completely eliminates the vulnerability without upgrading Tomcat. Per the noisgate mitigation SLA for HIGH, deploy within 30 days — but given the trivial nature of this config change, aim for same-week.

HIGH 7.5→IGNORE 0.0

SEVERITY REDUCED

Upgrade Tomcat to 11.0.27, 10.1.61, or 9.0.123 — Apply the vendor patch which forces simple bind during user authentication regardless of the configured SASL mechanism. This is the definitive remediation. Per the noisgate remediation SLA for HIGH, complete within 180 days. If you already applied the config workaround above, the patch becomes a defense-in-depth measure on a relaxed timeline.

HIGH 7.5→HIGH 7.5

Audit and enumerate all JNDIRealm configurations across fleet — Run the verification script (below) across all Tomcat hosts to identify which instances actually use JNDIRealm with a non-GSSAPI SASL mechanism. Most environments will find zero affected instances, allowing them to deprioritize the patch. Knowing your exposure is the first step.

HIGH 7.5→MEDIUM 5.5

SEVERITY REDUCED

Restrict network access to Tomcat login endpoints — Apply firewall rules or WAF policies to limit which source IPs can reach Tomcat authentication endpoints. This reduces the attack surface to trusted networks. Does not fix the vulnerability but raises the bar from 'any internet attacker' to 'attacker with internal network position.'

HIGH 7.5→HIGH 7.0

Enable LDAP server-side audit logging for SASL binds — Configure your LDAP directory (Active Directory, OpenLDAP, 389DS) to log all SASL bind attempts with outcome details. This won't prevent exploitation but creates a forensic trail if the bypass is used. Look for SASL binds that succeed without a proper credential exchange.

What doesn't work

Disabling GSSAPI/Kerberos — This CVE affects *non-GSSAPI* SASL mechanisms. Disabling GSSAPI does nothing; it may even push your config toward the vulnerable path if you were previously using GSSAPI (which has its own separate fix in CVE-2026-55957).
Rate limiting or account lockout — The auth bypass succeeds on the *first attempt*. There are no failed logins to trigger lockout thresholds.
Web Application Firewall (WAF) signature rules — The malicious request is a perfectly normal-looking login POST with a valid username and (wrong) password. There is no distinguishing payload, injection string, or malformed header for a WAF to match on.
Upgrading to Tomcat 8.5.x or 7.x latest — These branches are EOL and received no fix. You must migrate to a supported branch (9.0.123+, 10.1.61+, or 11.0.27+).

04 · Intelligence Metadata

The supporting signals.

In-the-Wild Exploitation	No confirmed exploitation. Not listed in CISA KEV. Apache's advisory does not mention active attacks. No campaigns or threat actor attribution as of 2026-10-22.
Proof-of-Concept Availability	No public PoC. Checked pocindex.io, GitHub (no repo named CVE-2026-101296), ExploitDB, and Nuclei templates — all negative. The fix commit is public and trivially reversible, so a PoC could be constructed by anyone who reads the diff, but none has surfaced yet.
EPSS	0.00652 (~65th percentile). Low exploitation probability in the next 30 days. Consistent with the narrow configuration prerequisite.
KEV Status	Not listed in CISA Known Exploited Vulnerabilities catalog as of 2026-10-22.
CVSS Assessment	CVSS v4.0: 9.1 (third-party, via strix.ai): `CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N`. The `AT:P` (Attack Prerequisites) accounts for the specific config requirement. No vendor-issued CVSS v3.1 vector exists. Estimated v3.1 equivalent: ~`AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N` ≈ 7.4 HIGH (AC:H reflects the configuration dependency).
Affected Versions	Tomcat 11.0.0-M1–11.0.26, 10.1.0-M1–10.1.60, 9.0.0.M1–9.0.122, 8.5.0–8.5.100 (EOL), 7.0.0–7.0.109 (EOL). Essentially every Tomcat release since 7.0.0 through October 2026.
Fixed Versions	11.0.27 (released 2026-10-12), 10.1.61, 9.0.123. No fix for EOL 8.5.x or 7.x — upgrade to a supported branch. Distro backports not yet available (check RHEL, Debian, Ubuntu trackers).
Exposure / Scanning Data	~300K+ Apache Tomcat instances indexed on Shodan globally (US, China, Brazil, Morocco leading). GreyNoise has observed coordinated brute-force activity targeting Tomcat Manager interfaces, though not specific to this CVE. The vulnerable configuration subset is orders of magnitude smaller.
Disclosure Timeline	Reported: 2026-09-14 → Fix committed: 2026-10-12 → Public disclosure: 2026-10-20. Roughly 36-day fix cycle. Related predecessor: CVE-2026-55957 (GSSAPI variant, fixed in 10.1.39, June 2026).
Reporter	Sai Sreewathsa Kovalluri, Shon Babu, and Kannan K of Innspark Solutions Private Limited. Same flaw class as the GSSAPI variant they or others reported earlier in 2026.

Sources.

05 · The Call

Final Verdict

= UNCHANGED to HIGH (7.5/10)

Why this verdict

Authentication bypass mechanism is complete and friction-free at the point of exploitation: Once the configuration prerequisite is met, the attacker needs only a valid username (no password) over the network. No user interaction, no special privileges, no complex exploit chain. The SASL bind fails open unconditionally. This is the textbook definition of a HIGH-severity auth bypass.
Configuration prerequisite dramatically narrows the vulnerable population: JNDIRealm with a non-GSSAPI SASL mechanism (DIGEST-MD5, CRAM-MD5) is a non-default, uncommon configuration. Tomcat ships with no realm; most LDAP integrations use simple bind (unaffected). DIGEST-MD5 was deprecated by RFC 6331 in 2011. Estimated affected population: <2% of Tomcat deployments, possibly <0.5%. This prevents CRITICAL.
No exploitation evidence compounds the low urgency signal: EPSS 0.00652, no KEV listing, no public PoC, no observed scanning. The fix commit is public and the bug is simple to understand, so a PoC *could* appear — but two days post-disclosure, the weaponization clock has not started.
Role multiplier: Tomcat is a general-purpose application server deployed across dev sandboxes (low-value), line-of-business app servers (typical), and occasionally as CI/CD frontends or hosting admin consoles (high-value). (a) For low/typical roles: auth bypass grants access to the specific application's data and functionality — serious but application-scoped, not domain/fleet-scoped. (b) For high-value roles: if the Tomcat Manager app is behind the vulnerable JNDIRealm config, bypass → WAR deployment → RCE → host compromise. However, Manager is almost never configured with JNDIRealm (it uses MemoryRealm/tomcat-users.xml by default) and is typically IP-restricted to localhost. The fraction of installs where the high-value-role chain succeeds AND the vulnerable config exists is estimated at <0.1% — below the 1% floor threshold. Tomcat is not a canonically high-value-role component (not an IdP, DC, hypervisor, PKI, or network edge). The floor does not trigger.
Apache's own severity of 'Important' supports HIGH: Apache's four-tier scale (Critical > Important > Moderate > Low) places this at their second-highest tier, aligning with our HIGH assessment.

Why not higher?

A CRITICAL rating would require either a universally exploitable condition or a canonically high-value-role component. This CVE requires a *specific, uncommon, non-default* Realm and SASL configuration that the vast majority of Tomcat deployments do not use. The CVSS v4.0 AT:P flag correctly captures this. There is no evidence of exploitation, no public PoC, and Tomcat is not a high-value-role-defining component like a domain controller or hypervisor. The blast radius is application-scoped, not fleet or identity-scoped.

Why not lower?

When the precondition IS met, the bypass is total — unauthenticated remote access with zero friction, zero user interaction, and zero complexity. A MEDIUM rating would understate the impact for the (small) population of affected systems, especially given that Apache themselves rated it Important and the mechanism requires no exploit sophistication. The existence of a public fix commit that trivially reveals the bug also means a PoC could appear at any time, compressing the window.

06 · Verification

Crowdsourced verification payload.

Run this script on each Tomcat host as the Tomcat service user or root. Pass CATALINA_HOME as the first argument, or let it auto-detect. Example: sudo bash cve-2026-101296-check.sh /opt/tomcat. Requires java on PATH for version detection (falls back to RELEASE-NOTES parsing). Exit codes: 0=PATCHED/NOT AFFECTED, 1=VULNERABLE, 2=UNKNOWN.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# CVE-2026-101296 Checker — Apache Tomcat JNDIRealm non-GSSAPI SASL auth bypass
# Usage: bash cve-2026-101296-check.sh [CATALINA_HOME]
# Exit codes: 0=PATCHED or NOT_AFFECTED, 1=VULNERABLE, 2=UNKNOWN
set -uo pipefail

CAT_HOME="${1:-${CATALINA_HOME:-}}"

# Auto-detect CATALINA_HOME
if [ -z "$CAT_HOME" ]; then
  for d in /opt/tomcat /usr/share/tomcat* /usr/local/tomcat /opt/apache-tomcat* /var/lib/tomcat*; do
    [ -f "$d/lib/catalina.jar" ] && CAT_HOME="$d" && break
  done
fi

if [ -z "$CAT_HOME" ] || [ ! -d "$CAT_HOME" ]; then
  echo "UNKNOWN — Cannot locate CATALINA_HOME. Pass it as the first argument."
  exit 2
fi
echo "[*] CATALINA_HOME: $CAT_HOME"

# --- Determine Tomcat version ---
TOMCAT_VER=""
if [ -f "$CAT_HOME/lib/catalina.jar" ] && command -v java &>/dev/null; then
  TOMCAT_VER=$(java -cp "$CAT_HOME/lib/catalina.jar" org.apache.catalina.util.ServerInfo 2>/dev/null \
    | grep -ioP 'Server number:\s*\K[0-9]+\.[0-9]+\.[0-9]+' | head -1 || true)
fi
if [ -z "$TOMCAT_VER" ] && [ -f "$CAT_HOME/RELEASE-NOTES" ]; then
  TOMCAT_VER=$(grep -ioP 'Apache Tomcat Version [0-9]+\.[0-9]+\.[0-9]+' "$CAT_HOME/RELEASE-NOTES" \
    | grep -oP '[0-9]+\.[0-9]+\.[0-9]+' | head -1 || true)
fi
if [ -z "$TOMCAT_VER" ]; then
  echo "UNKNOWN — Could not determine Tomcat version."
  exit 2
fi
echo "[*] Tomcat version: $TOMCAT_VER"

IFS='.' read -r MAJ MIN PAT <<< "$TOMCAT_VER"

# --- Version check ---
PATCHED=false
if   [ "$MAJ" -eq 11 ] && [ "$MIN" -eq 0 ] && [ "$PAT" -ge 27 ]; then PATCHED=true
elif [ "$MAJ" -eq 10 ] && [ "$MIN" -eq 1 ] && [ "$PAT" -ge 61 ]; then PATCHED=true
elif [ "$MAJ" -eq 9  ] && [ "$MIN" -eq 0 ] && [ "$PAT" -ge 123 ]; then PATCHED=true
elif [ "$MAJ" -gt 11 ]; then PATCHED=true
fi

if $PATCHED; then
  echo "PATCHED — Tomcat $TOMCAT_VER is at or above the fixed version."
  exit 0
fi

# --- Config scan for JNDIRealm with non-GSSAPI SASL ---
VULN_CFG=false
while IFS= read -r -d '' cfg; do
  # Match JNDIRealm elements
  if grep -qiP '<Realm\b[^>]*className\s*=\s*"org\.apache\.catalina\.realm\.JNDIRealm"' "$cfg" 2>/dev/null; then
    AUTH_VAL=$(grep -ioP '<Realm\b[^>]*className\s*=\s*"org\.apache\.catalina\.realm\.JNDIRealm"[^>]*authentication\s*=\s*"\K[^"]+' "$cfg" 2>/dev/null || true)
    if [ -n "$AUTH_VAL" ]; then
      AU=$(echo "$AUTH_VAL" | tr '[:lower:]' '[:upper:]')
      if [ "$AU" != "SIMPLE" ] && [ "$AU" != "NONE" ] && [ "$AU" != "GSSAPI" ]; then
        echo "[!] VULNERABLE CONFIG in $cfg: JNDIRealm authentication=\"$AUTH_VAL\""
        VULN_CFG=true
      fi
    fi
    # Also check if JNDIRealm exists without explicit authentication attr (safe — defaults to simple)
  fi
done < <(find "$CAT_HOME/conf" -name '*.xml' -type f -print0 2>/dev/null)

if $VULN_CFG; then
  echo "VULNERABLE — Tomcat $TOMCAT_VER with JNDIRealm using non-GSSAPI SASL. Patch or set authentication=\"simple\" immediately."
  exit 1
else
  echo "PATCHED — Tomcat $TOMCAT_VER is in the affected version range but NO JNDIRealm with non-GSSAPI SASL found in config. Not exploitable under current configuration. Still recommend patching."
  exit 0
fi