← Back to Feed CACHED · 2026-10-22 01:10:46 · CACHE_KEY CVE-2026-101356
CVE-2026-101356 · CWE-362 · Disclosed 2026-10-20

Apache Tomcat HTTP/2 async servlet cross-user response mix-up via object recycling race

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

Like leaving the wrong patient's chart on the next doctor's clipboard because the nurse recycled it too fast

CVE-2026-101356 is a race condition (CWE-362) in Apache Tomcat's HTTP/2 stream multiplexing layer. When an error occurs during asynchronous servlet processing, Tomcat's internal request/response objects are recycled back into a shared pool without properly clearing their state. A subsequent HTTP/2 stream can then receive these tainted objects, causing cross-user response mix-up — User B sees User A's response data (session tokens, PII, API payloads). Affected versions: Tomcat 11.0.22–11.0.26, 10.1.55–10.1.60, and 9.0.118–9.0.122. Fixed in 11.0.27, 10.1.61, and 9.0.123 respectively (commit 4b1eb9a1). Only Tomcat instances with the Http2Protocol UpgradeProtocol explicitly enabled in server.xml AND serving async servlets are vulnerable — both are opt-in features.

The vendor CVSS of 9.1 CRITICAL (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H) significantly overstates real-world risk. The AC:L (low attack complexity) rating is the core disagreement: this is a *race condition* that requires HTTP/2 (not enabled by default), asynchronous servlets (application-specific), AND an error during async processing to trigger faulty object recycling. That is textbook AC:H. Apache's own security team rated this Important — not Critical — which aligns far better with the actual prerequisites. Recalculating with AC:H yields CVSS 7.4, and the opt-in HTTP/2 requirement further narrows the exposed population to an estimated 10–20% of Tomcat deployments. No PoC exists, no in-the-wild exploitation has been observed, and EPSS sits at the 0.5th percentile.

"HTTP/2 opt-in + race condition + async servlets = narrow blast radius; downgrade from CRITICAL to HIGH"
02 · The Attack Path

5 steps from start to impact.

STEP 01

Establish HTTP/2 connection to Tomcat

The attacker connects directly to a Tomcat instance that has Http2Protocol configured as an UpgradeProtocol on its connector. This is the first gate: HTTP/2 must be enabled, which is NOT the default Tomcat configuration. In many production environments, a reverse proxy (nginx, HAProxy, AWS ALB, Cloudflare) terminates HTTP/2 and forwards HTTP/1.1 to Tomcat, making this step unreachable.
Conditions required:
  • Target Tomcat must have <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" /> in server.xml
  • Attacker must reach Tomcat's HTTP/2 endpoint directly (not behind an HTTP/2-terminating reverse proxy)
Where this breaks in practice:
  • HTTP/2 is opt-in, not default — most Tomcat deployments never enable it
  • Majority of production Tomcat sits behind L7 load balancers/reverse proxies that terminate HTTP/2
Detection/coverage: Version fingerprinting via HTTP response headers (Server: Apache-Coyote/1.1 or Server: Apache Tomcat/X.Y.Z); Shodan/Censys queries for exposed Tomcat with HTTP/2 ALPN negotiation.
STEP 02

Send concurrent requests targeting async servlet endpoints

The attacker sends multiple HTTP/2 streams multiplexed over a single connection, targeting endpoints that invoke AsyncContext.startAsync(). The attacker needs to identify which servlets use async processing — this may require reconnaissance via application behavior analysis, documentation, or error responses. Not all application endpoints use async servlets; many Java web apps use synchronous request handling exclusively.
Conditions required:
  • Application must use async servlets (javax.servlet.AsyncContext or jakarta.servlet.AsyncContext)
  • Attacker must identify async servlet endpoints
Where this breaks in practice:
  • Async servlets are an application-level architectural choice, not universal
  • Many enterprise Java apps still use synchronous servlet patterns (Spring MVC synchronous handlers, JSP/JSF)
Detection/coverage: Application-layer monitoring for unusual HTTP/2 stream concurrency patterns; WAF rules can flag high-multiplexing bursts but cannot prevent the underlying race.
STEP 03

Trigger or wait for async processing error

The vulnerability fires only when an error occurs during asynchronous processing, causing Tomcat to improperly recycle the request/response objects. The attacker may attempt to provoke errors by sending malformed payloads, oversized headers, or connection resets during async processing. However, the specific error conditions that trigger faulty recycling are internal to Tomcat's stream handling and may not be reliably inducible from the outside.
Conditions required:
  • An error must occur during async servlet processing on a concurrent stream
  • The error must hit the specific code path that triggers premature object recycling
Where this breaks in practice:
  • Error condition is not fully attacker-controlled — depends on internal Tomcat stream state
  • Without a PoC demonstrating reliable error induction, this step is probabilistic
Detection/coverage: Application error logs showing java.lang.IllegalStateException or async timeout exceptions in HTTP/2 stream processing; Tomcat access logs showing unexpected 500-series responses on async endpoints.
STEP 04

Race condition yields cross-user object contamination

When the faulty recycling occurs, the request/response object still carrying User A's data is returned to the pool and assigned to User B's HTTP/2 stream. The attacker, operating as one of the concurrent users, observes response data intended for another user. This is non-deterministic — the attacker cannot target a specific victim's session and may need many attempts to capture useful data. The leaked data could include session cookies, authorization headers, response bodies with PII, or API tokens.
Conditions required:
  • Race condition timing must align — the recycled object must be assigned to the attacker's stream
  • Concurrent legitimate user traffic must be present to create cross-contamination
Where this breaks in practice:
  • Non-deterministic: attacker cannot choose whose data they intercept
  • Low-traffic applications reduce the probability of useful cross-contamination
  • HTTP/2 flow control and stream priorities add timing unpredictability
Detection/coverage: Anomaly detection on response content (e.g., user A receiving user B's Set-Cookie header); application-level session integrity monitoring.
STEP 05

Exfiltrate leaked session data or PII

If the attacker successfully captures another user's session token or response data, they can replay the token for session hijacking or harvest PII directly. The value depends entirely on what the application returns in HTTP responses. Applications using token-based auth (JWT in response body) or returning sensitive data in API responses present the highest-value targets.
Conditions required:
  • Leaked response must contain actionable data (session tokens, PII, credentials)
  • Session tokens must not be bound to additional factors (IP, device fingerprint)
Where this breaks in practice:
  • Many modern apps use HttpOnly/Secure cookies reducing replay utility from response body alone
  • Token rotation and short-lived JWTs limit the window for session hijacking
  • The attacker sees random users' data, not targeted victims
Detection/coverage: Session anomaly detection (same session token used from different IPs/user agents); SIEM correlation of HTTP/2 stream errors with subsequent suspicious authentication events.
03 · Compensating Control

1
HIGH 6.8→IGNORE 0.0
SEVERITY REDUCED
Remove or comment out the Http2Protocol UpgradeProtocol from server.xml — The vulnerability exclusively affects HTTP/2 stream processing. Removing <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" /> from all <Connector> elements in server.xml and restarting Tomcat completely eliminates the attack surface. Tomcat will continue serving HTTP/1.1 normally. If HTTP/2 is needed for performance, terminate it at a reverse proxy (nginx, HAProxy) that forwards HTTP/1.1 to Tomcat. Deploy within 30 days per the noisgate mitigation SLA for HIGH.
2
HIGH 6.8→LOW 2.0
SEVERITY REDUCED
Place Tomcat behind an HTTP/2-terminating reverse proxy — If HTTP/2 client support is a business requirement, configure nginx, HAProxy, AWS ALB, or Cloudflare to handle HTTP/2 negotiation and proxy HTTP/1.1 to Tomcat's backend connector. This ensures Tomcat's HTTP/2 code path is never exercised, neutralizing the race condition. This is already the architecture for the majority of production Tomcat deployments. Deploy within 30 days per the noisgate mitigation SLA for HIGH.
3
HIGH 6.8→IGNORE 0.0
SEVERITY REDUCED
Upgrade to Tomcat 11.0.27 / 10.1.61 / 9.0.123 — The definitive fix. Commit 4b1eb9a1 corrects the object recycling logic in the HTTP/2 stream processor. For Spring Boot embedded Tomcat, update the tomcat.version property in your BOM or upgrade Spring Boot to a release that pulls the fixed Tomcat. For distro-packaged Tomcat (RHEL, Debian, Ubuntu), apply the vendor's backported package when available. Deploy within 180 days per the noisgate remediation SLA for HIGH.
4
HIGH 6.8→LOW 2.5
SEVERITY REDUCED
Disable async servlet support on HTTP/2 connectors — If your application can tolerate synchronous processing on HTTP/2 streams (or async is only used on a subset of endpoints), configure the application to avoid AsyncContext.startAsync() on HTTP/2-served endpoints. This is a narrow workaround — only viable if async usage is isolated and non-critical. It removes the second prerequisite from the attack chain.
What doesn't work
  • WAF rules — The vulnerability is a server-side race condition in object pool management. No request payload signature or header pattern can be blocked at the WAF layer to prevent it. A WAF cannot observe or interdict internal Tomcat memory operations.
  • Rate limiting / connection throttling — The race condition does not require high request volume. A small number of concurrent HTTP/2 streams during an async error is sufficient. Rate limiting may reduce probability slightly but does not prevent exploitation.
  • TLS configuration hardening — The bug is in Tomcat's HTTP/2 application-layer stream handling, not in TLS negotiation. Upgrading cipher suites or TLS versions has zero effect on this vulnerability.
  • Java Security Manager — Deprecated since Java 17, and even when active, the Security Manager operates at the Java API permission level and cannot prevent internal Tomcat object pool race conditions.
04 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationNone confirmed. Not listed on CISA KEV. No reports from GreyNoise, Shadowserver, or vendor incident response. The race condition nature makes mass exploitation impractical without a reliable trigger.
Proof-of-Concept AvailabilityNo public PoC found. Checked pocindex.io, GitHub (no repos named CVE-2026-101356), ExploitDB, Nuclei templates, and Metasploit modules. The race condition and multi-step prerequisites make PoC development non-trivial.
EPSS Score0.00518 (0.518%) — bottom quintile. FIRST's statistical model predicts very low probability of exploitation in the next 30 days, consistent with the absence of weaponization and the opt-in HTTP/2 prerequisite.
KEV StatusNot listed on CISA Known Exploited Vulnerabilities catalog as of 2026-10-22.
CVSS Vector AnalysisCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H = 9.1. The AC:L is disputed: a race condition requiring opt-in HTTP/2 + async servlets + error-state trigger is AC:H by the CVSS 3.1 specification. Recalculated with AC:H: 7.4. No integrity impact (I:N) — this is information disclosure and availability disruption, not code execution.
Affected VersionsTomcat 11: 11.0.22–11.0.26 · Tomcat 10.1: 10.1.55–10.1.60 · Tomcat 9: 9.0.118–9.0.122. Earlier versions within each major line (e.g., 9.0.0–9.0.117) are not affected. Tomcat 8.5.x is EOL and not listed.
Fixed Versions11.0.27, 10.1.61, 9.0.123. Distro backports: RHEL/CentOS track Tomcat 9 — watch for tomcat-9.0.123 in RHSA advisories. Debian/Ubuntu: check libservlet*-java package versions. Spring Boot embeds Tomcat — check spring-boot-starter-web dependency tree.
Internet Exposure~546K internet-facing Tomcat instances per Criminal IP (Oct 2025). Shodan shows ~156K with Tomcat/Coyote fingerprint. However, the fraction with HTTP/2 enabled directly on Tomcat (not terminated at a reverse proxy) is estimated at 10–20% of deployments, significantly narrowing the reachable population.
Disclosure TimelineReported to Apache security team: 2026-09-16. Fix committed: 4b1eb9a1. Fixed releases shipped: 2026-10-12. Public disclosure: 2026-10-20. Responsible 34-day disclosure window.
ReporterPublished by Mark Thomas (Apache Tomcat PMC Chair) via the ASF security mailing list and oss-security.

Sources.

  1. Apache Tomcat 9 Security Advisories
  2. ASF Mailing List — CVE-2026-101356 Advisory
  3. oss-security Disclosure (Mark Thomas)
  4. Tomcat HTTP/2 UpgradeProtocol Configuration Reference
  5. Criminal IP — Apache Tomcat Exposure Analysis (546K instances)
  6. Security Online — Apache Tomcat October 2026 Vulnerability Analysis
  7. GBHackers — Apache Tomcat Security Flaws Detail
  8. Fix Commit 4b1eb9a1
05 · The Call

Final Verdict
↓ DOWNGRADED to HIGH (6.8/10)

Why this verdict

  • AC:L is wrong for a race condition. The CVSS vector uses Attack Complexity: Low, but the vulnerability is a CWE-362 race condition requiring HTTP/2 (opt-in) + async servlets (app-specific) + an error during async processing + favorable timing. Per CVSS 3.1 specification §2.1.2, conditions beyond the attacker's control that must exist to exploit the vulnerability warrant AC:H. This single correction drops the base score from 9.1 to 7.4.
  • HTTP/2 is opt-in, not default. Tomcat ships with HTTP/1.1 connectors only; enabling HTTP/2 requires explicitly adding <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" /> to server.xml. The majority of production Tomcat instances sit behind reverse proxies (nginx, HAProxy, ALB, Cloudflare) that terminate HTTP/2 and forward HTTP/1.1 to Tomcat. Estimated reachable population: 10–20% of Tomcat deployments.
  • No PoC, no exploitation, EPSS floor. Zero public proof-of-concept code, no in-the-wild exploitation, not KEV-listed, and EPSS at 0.518% — all indicators of a vulnerability that has not been weaponized and may resist reliable weaponization due to its race condition nature.
  • Apache's own rating is Important, not Critical. The vendor's own security team — who wrote the code and understand the race window — classified this as Important severity. This is a meaningful signal that the CVSS 9.1 auto-score overstates the risk.
  • Impact ceiling is information disclosure, not RCE. The worst outcome is cross-user response leakage (C:H) and potential service disruption (A:H). There is no integrity impact (I:N) and no path to code execution. The attacker cannot target a specific victim — they receive random other users' data probabilistically.
  • Role multiplier: Tomcat as application server. Tomcat serves primarily as a Java application server tier (typical role). In high-value roles: (1) *Jenkins* runs on Tomcat but rarely exposes HTTP/2 directly — Jenkins uses HTTP/1.1 and its own Jetty/Winstone; (2) *Production web apps serving PII/financial data* — if HTTP/2 is enabled directly to Tomcat, cross-user data leakage could expose sensitive records, but blast radius is host-level (not domain/fleet/supply-chain); (3) Tomcat is not canonically an identity provider, hypervisor, backup system, or network edge device. The worst plausible high-value-role outcome is host-level user data exposure in the ~10-20% of deployments with HTTP/2 enabled — this floors the verdict at HIGH but does not reach CRITICAL.

Why not higher?

This is not CRITICAL because the vulnerability requires multiple opt-in preconditions (HTTP/2 enabled, async servlets in use, error condition during processing) that compound to narrow the reachable population to a fraction of Tomcat deployments. The impact ceiling is information disclosure and availability disruption — not code execution, privilege escalation, or authentication bypass. There is no path from this vulnerability to domain takeover, fleet compromise, or supply-chain impact. Apache's own team rated it Important, and EPSS agrees at the 0.5th percentile.

Why not lower?

This is not MEDIUM because Tomcat is one of the most widely deployed application servers on the internet (~546K exposed instances), the vulnerability is pre-authentication (no credentials needed), and when the race condition does fire in a deployment with HTTP/2 and async servlets, the confidentiality impact is HIGH — session tokens, PII, and API responses from other users can leak. The ~10-20% of deployments with direct HTTP/2 still represents tens of thousands of instances. The availability impact (A:H) adds further weight. A defender managing 10,000 hosts likely has some Tomcat instances in this configuration.

06 · Verification

Crowdsourced verification payload.

Run this script on each Tomcat host (or via your configuration management tool across the fleet) as any user with read access to $CATALINA_HOME. Usage: bash check_cve_2026_101356.sh /opt/tomcat — substitute your Tomcat install path. No root required. For Spring Boot embedded Tomcat, check the tomcat-embed-core JAR version in your application's lib/ or dependency tree instead.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# CVE-2026-101356 checker — Apache Tomcat HTTP/2 async object recycling race condition
# Exit codes: 0=PATCHED  1=VULNERABLE  2=UNKNOWN
set -euo pipefail

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

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

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

echo "[*] CATALINA_HOME: $CATALINA_HOME"

# --- Detect version ---
VERSION=""
if [[ -x "$CATALINA_HOME/bin/version.sh" ]]; then
  VERSION=$("$CATALINA_HOME/bin/version.sh" 2>/dev/null | grep -oP 'Server number:\s*\K[\d.]+' || true)
fi
if [[ -z "$VERSION" ]] && command -v unzip &>/dev/null; then
  VERSION=$(unzip -p "$CATALINA_HOME/lib/catalina.jar" \
    org/apache/catalina/util/ServerInfo.properties 2>/dev/null \
    | grep '^server.number=' | cut -d= -f2 | tr -d '[:space:]' || true)
fi
if [[ -z "$VERSION" ]]; then
  echo "UNKNOWN — Could not determine Tomcat version."
  exit 2
fi
echo "[*] Tomcat version: $VERSION"

# --- Parse version ---
IFS='.' read -r MAJ MIN PAT <<< "$VERSION"
MAJ=${MAJ:-0}; MIN=${MIN:-0}; PAT=${PAT:-0}

# --- Check affected ranges ---
IN_RANGE=0
if   [[ $MAJ -eq 11 && $MIN -eq 0 && $PAT -ge 22 && $PAT -le 26 ]]; then IN_RANGE=1
elif [[ $MAJ -eq 10 && $MIN -eq 1 && $PAT -ge 55 && $PAT -le 60 ]]; then IN_RANGE=1
elif [[ $MAJ -eq  9 && $MIN -eq 0 && $PAT -ge 118 && $PAT -le 122 ]]; then IN_RANGE=1
fi

if [[ $IN_RANGE -eq 0 ]]; then
  echo "PATCHED — Tomcat $VERSION is outside the affected range."
  exit 0
fi

# --- Check for HTTP/2 UpgradeProtocol ---
H2=0
CONF="$CATALINA_HOME/conf"
if grep -rql 'Http2Protocol' "$CONF/" 2>/dev/null; then
  H2=1
  echo "[!] HTTP/2 UpgradeProtocol FOUND in server.xml"
else
  echo "[*] HTTP/2 UpgradeProtocol not found in $CONF/"
fi

if [[ $H2 -eq 0 ]]; then
  echo "PATCHED (effective) — Version $VERSION is in the affected range but HTTP/2"
  echo "  is NOT enabled. Vulnerability requires HTTP/2. Upgrade still recommended."
  exit 0
fi

echo "=========================================="
echo "VULNERABLE — Tomcat $VERSION with HTTP/2 enabled."
echo "  Fix: upgrade to 11.0.27 / 10.1.61 / 9.0.123"
echo "  Workaround: remove Http2Protocol from server.xml"
echo "=========================================="
exit 1