Tenable stapled a 9.8 CVSS to a digest-auth bug that even its own proof-of-concept can't exploit against a vanilla Realm
This Tenable plugin (314334) bundles seven CVEs fixed in Apache Tomcat 9.0.118, spanning versions 9.0.0.M1 through 9.0.117. The headline driver is CVE-2026-43512, a digest-authentication bypass where RealmBase.getDigest() silently stringifies a null password return as the literal "null", letting an attacker compute a valid DIGEST response for any nonexistent username. Also notable is CVE-2026-43515, a security-constraint bypass where multiple <web-resource-collection> blocks sharing the same URL pattern but declaring different HTTP methods causes Tomcat to enforce only the first method constraint. The remaining five CVEs — AJP secret timing leak (43514), LockOutRealm case-sensitivity gap (43513), WebSocket auth-header leakage (42498), HTTP/2 header validation gap (41293), and WebDAV unbounded-read DoS (41284) — are all rated Low by Apache themselves.
The vendor CRITICAL/9.8 label does not match reality. The NVD vector for CVE-2026-43512 assumes C:H/I:H/A:H with no prerequisites — but DIGEST authentication is a non-default, rarely deployed configuration that Red Hat explicitly calls *"not a common, out of the box and expected configuration."* More damning: the public PoC from covepseng/cve-2026-43512-poc demonstrates that even when digest hashes match, standard UserDatabaseRealm deployments return null from getPrincipal(), triggering a 401 regardless. Red Hat independently scored this at 6.5 Moderate, and Tenable's own VPR model rates the entire plugin at 4.9 Medium. CVE-2026-43515 is the more operationally relevant flaw — its PoC confirms a working bypass — but it requires a specific multi-constraint web.xml pattern that departs from standard servlet security idioms. When Tenable's own risk model disagrees with its own severity label, listen to the risk model.
4 steps from start to impact.
Identify internet-facing Tomcat with DIGEST auth
WWW-Authenticate: Digest headers. Shodan shows ~100K internet-facing Tomcat servers, but the fraction configured for DIGEST authentication (vs. FORM, BASIC, or delegated SSO) is vanishingly small — realistically under 1%. Most production Tomcat instances sit behind a reverse proxy that handles authentication entirely.- Target Tomcat must be directly reachable over HTTP/HTTPS
- Tomcat must be configured with
<auth-method>DIGEST</auth-method>inweb.xml
- DIGEST auth is a legacy HTTP mechanism superseded by FORM auth, OIDC, and SAML — virtually no modern Java app uses it
- Enterprise Tomcat deployments almost universally sit behind Apache httpd, Nginx, or a load balancer that terminates auth
- Red Hat explicitly states DIGEST auth is not a common production configuration
Authorization: Digest headers with unknown usernames would indicate probing.Compute DIGEST response with 'null' password
"null" as the password. The Go-based PoC from covepseng/cve-2026-43512-poc automates this: A1 = MD5(username:realm:null). The resulting Authorization: Digest header will match what the server computes for any username not found in the Realm.- Step 1 conditions met
- Attacker can reach the DIGEST-protected endpoint
- The PoC author themselves documented that exploitation fails against standard
UserDatabaseRealmbecausegetPrincipal()returns null for nonexistent users, triggering 401 - Custom Realm implementations that return a non-null Principal for unknown users would be required for full bypass — an unusual and insecure custom implementation
Authorization: Digest with the literal password hash of 'null' are trivial to write.Attempt resource access as phantom user
<security-constraint> with <role-name> restrictions (the standard pattern) will still deny access at the authorization layer. The attacker would need the application to grant access to any authenticated user regardless of role — a permissive misconfiguration on top of the already-rare DIGEST auth setup.- Non-standard Realm that returns Principal for unknown users
- Application grants access without role-based authorization checks
- Standard servlet security constraints enforce role-based access — authentication alone is insufficient
- Even Red Hat notes the bypassed user 'does not steal credentials nor impersonate an existing user' and lacks 'valid realm roles'
Alternative: CVE-2026-43515 constraint bypass via HTTP method
web.xml defines a single <security-constraint> with multiple <web-resource-collection> blocks sharing the same URL extension pattern but specifying different HTTP methods (e.g., GET in one, POST in another), Tomcat only enforces the first collection. The attacker can send a POST to a resource only constrained by the second collection, bypassing authorization entirely. The covepseng/cve-2026-43515-poc confirms exploitation succeeds.- Target application uses multi-collection constraint pattern with shared URL extensions
- The unprotected HTTP method accesses meaningful functionality
- This web.xml pattern is non-standard — most applications use a single collection with multiple methods or omit method constraints entirely (protecting all methods)
- Developers following the Servlet specification's recommendation to avoid method-level constraints are unaffected
- The attacker must discover the specific extension pattern and unprotected method through enumeration
The supporting signals.
| In-the-wild exploitation | No evidence. Not in CISA KEV. No campaigns reported by Mandiant, CrowdStrike, or Rapid7 as of September 2026. GreyNoise shows no exploitation telemetry for these CVEs. |
|---|---|
| Proof-of-concept | Two public PoCs. covepseng/cve-2026-43512-poc (Go) demonstrates digest hash matching but fails to achieve bypass against standard UserDatabaseRealm. covepseng/cve-2026-43515-poc (Go) confirms working bypass for the constraint issue. Neither is weaponized or integrated into Metasploit/Nuclei. |
| EPSS | CVE-2026-43512: 0.87% probability of exploitation in 30 days (54th percentile). Low signal — well below the 5% threshold that typically correlates with active campaigns. |
| CISA KEV status | Not listed. None of the seven CVEs appear in the Known Exploited Vulnerabilities catalog as of 2026-09-21. |
| CVSS vectors | CVE-2026-43512 — NVD: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (9.8); Red Hat: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N (6.5 Moderate). CVE-2026-43515 — Red Hat: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N (5.4 Moderate). The NVD 9.8 assumes high CIA impact that doesn't materialize against standard Realms. |
| Tenable VPR | 4.9 (Medium) — Tenable's own risk-prioritization model contradicts the CRITICAL label on this plugin. VPR accounts for exploit maturity and threat context. |
| Affected versions | 9.0.0.M1 through 9.0.117 (also affects 11.0.0-M1–11.0.21, 10.1.0-M1–10.1.54, 8.5.0–8.5.100). CVE-2026-42498 starts at 9.0.2. |
| Fixed versions | 9.0.118 (also 11.0.22, 10.1.55). RHEL/CentOS backports: check tomcat-9.0.118 packages in RHSA advisories. Debian/Ubuntu track tomcat9 package versions against their own security trackers. |
| Internet exposure | Shodan indexes ~100K internet-facing Tomcat servers globally. However, the fraction using DIGEST auth or the specific multi-constraint web.xml pattern is estimated at <1% of the exposed population. Most production Tomcat sits behind reverse proxies. |
| Disclosure timeline | Reported: 2026-04-11 through 2026-04-21. Public disclosure: 2026-05-12. Fix available: 2026-05-10 (9.0.118 released). Tenable plugin published: 2026-05-12. |
Why this verdict
- Headline CVE's own PoC fails: The public proof-of-concept for CVE-2026-43512 documents that standard
UserDatabaseRealmdeployments are not exploitable —getPrincipal()returns null for unknown users, resulting in 401 regardless of digest match. A 9.8 for a bug that doesn't work against default configs is fiction. - DIGEST auth is a dead protocol in enterprise Java: Red Hat explicitly states this is *"not a common, out of the box and expected configuration for Production environments."* Realistic population of affected instances is <1% of the Tomcat install base. This alone justifies a 3+ point downward adjustment from the NVD score.
- Even successful bypass yields no roles: The authenticated phantom user has no Realm roles. Any application using standard
<security-constraint>with<role-name>entries — the overwhelming majority — denies access at the authorization layer. The NVD vector'sC:H/I:H/A:Htriple-high is not achievable. - CVE-2026-43515 is real but narrowly triggered: The constraint bypass PoC works, but requires a specific multi-collection
web.xmlpattern that departs from standard servlet security idioms. Red Hat independently scored this at 5.4 Moderate. - Tenable's own risk model disagrees: The VPR of 4.9 (Medium) reflects exploit maturity, threat intelligence, and real-world risk — it directly contradicts the CRITICAL label inherited from the NVD's theoretical CVSS.
- Role multiplier: Tomcat occupies the application-tier role, which can serve critical workloads. In CI/CD (Jenkins embeds Tomcat), container orchestration (Spring Boot), and production app tiers, Tomcat is prevalent. However, these high-value deployments do *not* use container-managed DIGEST auth — they delegate authentication to Spring Security, OIDC/SAML providers, or reverse proxies. CVE-2026-43515's constraint bypass is the only plausible concern in high-value roles, but its blast radius is limited to the specific endpoints behind the misconfigured constraint — not domain/fleet/supply-chain scale. The floor does not force HIGH because the vulnerable configuration is not canonical to any high-value role.
- No exploitation pressure: Not in CISA KEV, EPSS is 0.87% (54th percentile), no reported campaigns, no GreyNoise telemetry. Five of the seven CVEs are rated Low by Apache themselves.
Why not higher?
Upgrading to HIGH would require either active exploitation evidence or a realistic path to high-value-target compromise from the default configuration. Neither exists. The headline CVE's PoC fails against standard deployments, DIGEST auth prevalence is negligible, and the constraint bypass (CVE-2026-43515) requires a non-standard web.xml pattern with host-level (not fleet-level) blast radius. The EPSS and VPR signals both indicate low exploitation likelihood.
Why not lower?
CVE-2026-43515 has a confirmed working PoC that bypasses authorization constraints without authentication under specific configurations. While the trigger conditions are uncommon, they are not impossible — a defender cannot rule out that some subset of their Tomcat fleet uses multi-collection constraint patterns. The seven CVEs together represent a meaningful defense-in-depth improvement, and the internet-facing Tomcat population is large enough (~100K) that some instances will be vulnerable. LOW would understate the residual risk from CVE-2026-43515.
What to do — in priority order.
- Audit web.xml for DIGEST auth and multi-constraint patterns — Before patching, run a fleet-wide scan of
web.xmlfiles across your Tomcat estate. Search for<auth-method>DIGEST</auth-method>(CVE-2026-43512 prerequisite) and for<security-constraint>blocks containing multiple<web-resource-collection>elements sharing the same<url-pattern>with different<http-method>values (CVE-2026-43515 prerequisite). Any hits represent genuinely exposed instances that should be prioritized. For a MEDIUM verdict, the noisgate remediation SLA gives you 365 days to patch, with no formal mitigation SLA — but instances matching these patterns should be treated as HIGH-priority exceptions. - Switch DIGEST auth to FORM or delegate to SSO/reverse proxy — If any Tomcat instances use DIGEST auth, switch to FORM authentication (over TLS) or delegate authentication to an identity provider via SAML/OIDC. This eliminates CVE-2026-43512 entirely without waiting for a Tomcat upgrade. The change requires a
web.xmlupdate and service restart. - Consolidate security constraints to avoid multi-collection patterns — Refactor
web.xmlto use a single<web-resource-collection>per<security-constraint>with all HTTP methods listed together, or omit<http-method>entirely to protect all methods. This eliminates CVE-2026-43515. Test with the Go PoC fromcovepseng/cve-2026-43515-pocbefore and after. - Restrict AJP connector to localhost — Bind the AJP connector to
address="127.0.0.1"and require a secret (secret="<strong-random>"). This mitigates CVE-2026-43514's timing attack and is a long-standing best practice. Most containerized Tomcat deployments already do this. - Disable WebDAV servlet if unused — Remove or comment out the
webdavservlet mapping inweb.xmlto eliminate CVE-2026-41284's unbounded-read DoS vector. The WebDAV servlet is not enabled by default but may be present in legacy deployments. - Upgrade to Tomcat 9.0.118+ — The definitive fix for all seven CVEs. Per the noisgate remediation SLA for MEDIUM, deploy within 365 days. Prioritize instances where the web.xml audit (above) found DIGEST auth or multi-constraint patterns.
- WAF rules for DIGEST auth bypass — The attack uses legitimate HTTP DIGEST protocol mechanics with valid hash computations. WAF signature matching cannot distinguish a malicious DIGEST response from a legitimate one without correlating against the identity store, which WAFs do not do.
- Rate limiting / brute-force protection — CVE-2026-43512 is a single-request bypass, not a brute-force attack. LockOutRealm and rate limiters are irrelevant. Similarly, CVE-2026-43513 (LockOutRealm case sensitivity) is a weakness in brute-force protection, not something rate limiting at the network layer can compensate for.
- Network segmentation alone — While putting Tomcat behind a reverse proxy eliminates direct exposure of DIGEST auth headers, it does not fix CVE-2026-43515 (constraint bypass), which operates at the application layer regardless of network position.
Crowdsourced verification payload.
Run this script on each Tomcat host (or remotely via SSH/Ansible). It checks the installed Tomcat version by inspecting catalina.jar's MANIFEST.MF or the version.sh output. Requires read access to CATALINA_HOME. Invoke as: bash check_tomcat_314334.sh /opt/tomcat (pass your CATALINA_HOME path as the first argument). No root required — just read access to the Tomcat installation directory.
#!/usr/bin/env bash
# check_tomcat_314334.sh — Verify Apache Tomcat against Tenable 314334
# Checks if Tomcat 9.x is below 9.0.118 (vulnerable to 7 CVEs)
# Usage: bash check_tomcat_314334.sh /path/to/CATALINA_HOME
# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=UNKNOWN
set -euo pipefail
CATALINA_HOME="${1:-${CATALINA_HOME:-}}"
if [[ -z "$CATALINA_HOME" ]]; then
echo "UNKNOWN — supply CATALINA_HOME as argument or environment variable"
exit 2
fi
# Try version.sh first
VERSION=""
if [[ -x "$CATALINA_HOME/bin/version.sh" ]]; then
VERSION=$("$CATALINA_HOME/bin/version.sh" 2>/dev/null | grep -oP 'Server number:\s*\K[0-9]+\.[0-9]+\.[0-9]+' || true)
fi
# Fallback to catalina.jar manifest
if [[ -z "$VERSION" ]]; then
JAR="$CATALINA_HOME/lib/catalina.jar"
if [[ -f "$JAR" ]]; then
VERSION=$(unzip -p "$JAR" META-INF/MANIFEST.MF 2>/dev/null | grep -oP 'Implementation-Version:\s*\K[0-9]+\.[0-9]+\.[0-9]+' || true)
fi
fi
if [[ -z "$VERSION" ]]; then
echo "UNKNOWN — could not determine Tomcat version from $CATALINA_HOME"
exit 2
fi
echo "Detected Tomcat version: $VERSION"
# Parse major.minor.patch
IFS='.' read -r MAJOR MINOR PATCH <<< "$VERSION"
# Only assess Tomcat 9.x
if [[ "$MAJOR" -ne 9 ]]; then
echo "UNKNOWN — this check targets Tomcat 9.x; detected ${MAJOR}.x"
echo "For Tomcat 10.x, fixed version is 10.1.55; for 11.x, fixed version is 11.0.22"
exit 2
fi
# Vulnerable: 9.0.0 through 9.0.117
# Fixed: 9.0.118+
if [[ "$MINOR" -eq 0 && "$PATCH" -lt 118 ]]; then
echo "VULNERABLE — Tomcat $VERSION is below 9.0.118 (Tenable 314334 / CVE-2026-43512 et al.)"
# Check for DIGEST auth and multi-constraint patterns
echo ""
echo "--- Configuration Risk Check ---"
WEBXML=$(find "$CATALINA_HOME" -name 'web.xml' -path '*/WEB-INF/*' 2>/dev/null || true)
if [[ -n "$WEBXML" ]]; then
DIGEST_HIT=$(grep -ril 'DIGEST' $WEBXML 2>/dev/null || true)
if [[ -n "$DIGEST_HIT" ]]; then
echo "WARNING: DIGEST auth found in: $DIGEST_HIT"
echo " -> CVE-2026-43512 is DIRECTLY APPLICABLE to this instance"
else
echo "OK: No DIGEST auth configured (CVE-2026-43512 not exploitable)"
fi
else
echo "INFO: No WEB-INF/web.xml files found to inspect"
fi
exit 1
else
echo "PATCHED — Tomcat $VERSION is >= 9.0.118"
exit 0
fiWhat defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.