Apache Tomcat's h2c (HTTP/2 cleartext) upgrade mechanism became the source of a subtle but serious information-disclosure bug in early 2021, tracked as CVE-2021-25122. Under specific timing conditions, Tomcat's HTTP/1.1 connector could mismanage buffered request data during an h2c protocol upgrade, causing the server to return a response intended for one user's request to a different, concurrent user — or to graft another request's headers and a portion of its body onto an unrelated connection. In plain terms: on a busy Tomcat instance, User A could receive a response payload meant for User B, or vice versa. In multi-tenant deployments, API gateways, or any environment where a single Tomcat instance serves many independent clients over pooled connections, that kind of cross-request contamination can leak session tokens, authentication headers, personal data, or any other sensitive content embedded in HTTP responses.
This is the class of bug that security teams tend to underestimate because it doesn't look like a classic injection or auth-bypass flaw — there's no exploit payload to sign, no obvious indicator of compromise. It's a protocol-state-handling defect that manifests only under specific concurrency and timing conditions, which is exactly why it's worth understanding clearly rather than filing away as "just another Tomcat patch."
Affected Versions and Components
CVE-2021-25122 affects the h2c upgrade handling in Apache Tomcat's Coyote HTTP/1.1 connector — the code path that processes a client's request to upgrade a plaintext HTTP/1.1 connection to HTTP/2 without TLS. The affected version ranges are:
- Apache Tomcat 10.0.0-M1 through 10.0.5
- Apache Tomcat 9.0.0.M1 through 9.0.43
- Apache Tomcat 8.5.0 through 8.5.63
Tomcat 7.x and earlier are not affected, since HTTP/2 support (and with it, the h2c upgrade path) was introduced starting with the Tomcat 9 line. The issue is specific to cleartext h2c upgrade negotiated over HTTP/1.1; HTTP/2 connections established via TLS ALPN negotiation are a separate code path and are not implicated by this CVE. Any product or platform that embeds one of the affected Tomcat versions — standalone deployments, Spring Boot applications with embedded Tomcat, or commercial appliances bundling Tomcat — inherits the exposure.
CVSS, EPSS, and KEV Context
NVD lists CVE-2021-25122 with a CVSS v3.1 base score of 7.5 (High), reflecting a network-exploitable vulnerability with high attack complexity, no privileges or user interaction required, and an impact confined to confidentiality (no direct integrity or availability impact). The "high attack complexity" component matters here: successfully triggering the mix-up depends on request timing and connection reuse patterns that an attacker cannot fully control, which meaningfully raises the bar for reliable exploitation compared to a straightforward network-reachable flaw.
Consistent with that complexity profile, this CVE has not shown meaningful exploitation activity in the wild, and it does not appear on CISA's Known Exploited Vulnerabilities (KEV) catalog. EPSS scoring for this vulnerability has remained low, tracking the reality that reliably weaponizing a request-mix-up race condition is far harder than exploiting, say, an unauthenticated remote code execution bug. That said, "low EPSS" is not the same as "no risk" — for organizations handling regulated data (health records, financial data, credentials) through Tomcat-fronted APIs, even a low-probability cross-user data leak carries outsized compliance and breach-notification consequences, and CVSS 7.5 alone is enough to trigger patch SLAs under most vulnerability management policies.
Timeline
The issue was reported to the Apache Tomcat Security Team by security researcher Yaniv Nizry of Cybereason, part of a broader review of Tomcat's HTTP/2 and h2c handling around that time. The Apache Tomcat project fixed the flaw and shipped patched releases — Apache Tomcat 8.5.64, 9.0.44, and 10.0.6 — during its March 2021 release cycle, publishing the advisory and requesting the CVE-2021-25122 identifier alongside the fix.
Notably, the initial patch turned out to be incomplete. A follow-up advisory, CVE-2021-25329, was later issued to address residual request mix-up scenarios that the first fix didn't fully close. That second round of fixes landed in Apache Tomcat 8.5.68, 9.0.48, and 10.0.9. Any remediation plan for CVE-2021-25122 should account for this — patching only to the versions that resolved the original CVE leaves a related, narrower variant of the same underlying weakness unaddressed.
Remediation Steps
- Upgrade past both fixes, not just the first one. Target Apache Tomcat 8.5.68+, 9.0.48+, or 10.0.9+ (rather than stopping at 8.5.64/9.0.44/10.0.6) to ensure both CVE-2021-25122 and the follow-on CVE-2021-25329 are resolved.
- Disable h2c upgrade support if you can't patch immediately. In practice, no mainstream browser initiates h2c upgrade negotiation, so the feature carries very limited legitimate utility for most deployments. Removing or reconfiguring the
UpgradeProtocolelement tied to HTTP/2 inserver.xmlso the HTTP/1.1 connector no longer advertises h2c upgrade support eliminates the vulnerable code path entirely as a stopgap. - Confirm your HTTP/2 usage is TLS/ALPN-based, not cleartext upgrade. If your Tomcat instances only serve HTTP/2 via TLS, your exposure to this specific flaw is inherently limited, but it's worth explicitly verifying connector configuration rather than assuming.
- Inventory embedded and vendored Tomcat instances. Standalone Tomcat installs are the easy case; the harder ones are Tomcat bundled inside Spring Boot fat JARs, internal tooling, or third-party appliances where the version isn't obvious from a package manager listing.
- Check reverse proxy and load balancer connection-reuse behavior. Because the flaw hinges on connection pooling and concurrent request timing, front-end infrastructure that aggressively reuses backend connections can change your practical exposure window; review configurations as part of your risk assessment, not just the Tomcat version itself.
- Validate the fix after upgrading. Re-run your standard integration and load tests post-patch to confirm no regressions in HTTP/2 negotiation behavior, and update your SBOM/asset inventory to reflect the new Tomcat version so future audits reflect reality.
How Safeguard Helps
CVE-2021-25122 is a textbook example of why software supply chain visibility has to go deeper than "what's in my package.json." The vulnerable component here is Apache Tomcat — a piece of infrastructure that shows up not just as a direct dependency, but embedded inside application frameworks, vendor products, and internal platform tooling where it's easy to lose track of the exact version in use.
Safeguard addresses this by building and continuously maintaining accurate SBOMs across your build and deployment pipeline, so embedded Tomcat instances — whether pulled in transitively through Spring Boot, bundled in a third-party appliance, or running standalone — are identified and mapped to real CVEs, not just flagged generically as "outdated dependency."
Because CVE-2021-25122 sits at CVSS 7.5 with low EPSS and no KEV listing, it's exactly the kind of finding that gets either over-prioritized by CVSS-only scanners or silently deprioritized by teams chasing headline CVEs. Safeguard correlates CVSS severity with EPSS exploitation likelihood and KEV status to give teams a realistic, risk-ranked view — surfacing that this issue warrants scheduled patching (and awareness of the CVE-2021-25329 follow-up) without triggering unnecessary incident-response overhead for a vulnerability with no evidence of active exploitation.
Finally, Safeguard's policy enforcement integrates into CI/CD to prevent builds from shipping with known-vulnerable Tomcat versions going forward, and can drive automated remediation workflows — opening version-bump pull requests across affected services — so that closing out findings like this one doesn't depend on someone remembering to check the Apache Tomcat security page months after the fix has already shipped.