← Back to Feed CACHED · 2026-09-21 08:21:00 · CACHE_KEY tenable:323710
tenable:323710 · CWE-304 · Disclosed 2026-06-29

Apache Tomcat 9.0.0.M1 < 9.0.102

ASSESSED — NOISGATE
Vendor
Reassessed
Verdict:
Do you agree?
01 · The Real Story

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.

"Auth bypass in a niche Tomcat config; most flagged hosts are false positives"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Identify Tomcat with JNDIRealm + GSSAPI

The attacker discovers an internet- or intranet-facing Tomcat instance that uses JNDIRealm configured with 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.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Nessus plugin 323710 (version-only check, does NOT validate realm configuration). Qualys QID likely similar version-only detection.
STEP 02

Enumerate valid usernames

The attacker needs at least one valid username in the LDAP directory that JNDIRealm queries. This could come from OSINT (LinkedIn, email conventions), prior credential dumps, or timing-based username enumeration against the login form. In enterprise environments integrated with Active Directory, usernames often follow predictable patterns (first.last, flast).
Conditions required:
  • Knowledge of at least one valid username in the backing LDAP/AD directory
Where this breaks in practice:
  • Applications behind JNDIRealm often use non-obvious internal usernames
  • Rate limiting or account lockout policies may block enumeration
Detection/coverage: Failed login monitoring, WAF login-rate rules
STEP 03

Submit credentials with wrong/empty password

The attacker submits an HTTP request to the Tomcat login endpoint (form-based, BASIC, or 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.
Conditions required:
  • Steps 1 and 2 satisfied
  • The application uses Tomcat's container-managed authentication (not a custom auth filter that bypasses Realm)
Where this breaks in practice:
  • 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
Detection/coverage: Authentication logs showing successful login without corresponding Kerberos ticket validation. SIEM correlation of login events vs. KDC ticket-granting logs.
STEP 04

Access application as authenticated user

With a valid session, the attacker accesses the application with the privileges of the impersonated user. The CVSS vector rates Confidentiality, Integrity, and Availability impact as Low — meaning the attacker gains access to some data and some modification capability, but not full control. The blast radius is scoped to whatever the Tomcat-hosted application exposes to the impersonated user role.
Conditions required:
  • Successful authentication bypass from Step 3
Where this breaks in practice:
  • 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
Detection/coverage: Anomalous session activity from unexpected source IPs. Application audit logs showing actions by the impersonated user.
03 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationNo evidence. Not listed in CISA KEV. No campaigns or threat actor usage reported as of 2026-09-21.
Proof-of-ConceptNone 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 Score2.863% (86th percentile) — moderate exploitation probability, above average but not alarming.
CISA KEV StatusNot listed as of 2026-09-21.
CVSS VectorCVSS: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 VersionsTomcat 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 Versions9.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 VPR2.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.
CreditDiscovered by Ilan Toyter. Disclosed 2026-06-29 via Apache security mailing list.
04 · The Call

Final Verdict
DOWNGRADED to MEDIUM (5.0/10)

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.

05 · Compensating Control

What to do — in priority order.

  1. Confirm your Realm configuration before patching — Run grep -ri 'JNDIRealm' $CATALINA_BASE/conf/server.xml and check for authentication="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.
  2. 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).
  3. 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.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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
fi
07 · Sources

Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.