CVE-2021-25122 Overview
CVE-2021-25122 is an information disclosure vulnerability in Apache Tomcat affecting how the server handles new HTTP/2 cleartext (h2c) connection requests. When responding to h2c upgrade requests, vulnerable Tomcat versions could duplicate request headers and a limited portion of the request body from one request to another. The result is that user A and user B could both receive the response intended for user A's request, exposing sensitive data such as authentication tokens, session cookies, or personally identifiable information across user sessions. The flaw is classified under CWE-200: Exposure of Sensitive Information to an Unauthorized Actor.
Critical Impact
Cross-request data leakage between unrelated users over h2c connections can expose session cookies, authorization headers, and request bodies to attackers on the network.
Affected Products
- Apache Tomcat 10.0.0-M1 to 10.0.0
- Apache Tomcat 9.0.0.M1 to 9.0.41 and 8.5.0 to 8.5.61
- Debian Linux 9 and 10, plus multiple Oracle products (Agile PLM, Database 12.2/19c/21c, Communications Cloud Native Core Policy, MySQL Enterprise Monitor, Siebel UI Framework, Managed File Transfer, Graph Server and Client, Instantis EnterpriseTrack)
Discovery Timeline
- 2021-03-01 - Apache Tomcat project publishes advisory on the Openwall oss-security list
- 2021-03-01 - CVE-2021-25122 published to NVD
- 2024-11-21 - Last updated in NVD database
Technical Details for CVE-2021-25122
Vulnerability Analysis
The vulnerability resides in Tomcat's HTTP/2 upgrade handling path. HTTP/2 cleartext (h2c) allows a client to upgrade an existing HTTP/1.1 connection to HTTP/2 without TLS by sending an Upgrade: h2c header. During this upgrade transition, Tomcat constructs internal request objects that carry the original request data forward into the HTTP/2 stream. A logic flaw in this handoff allowed request state — specifically headers and a bounded amount of request body content — to be reused across concurrent or subsequent requests served by the same server worker.
The practical impact is a confidentiality breach across user sessions. An attacker sending a crafted h2c upgrade request can receive headers or partial body content originally bound to another user's in-flight request. This data may include Authorization headers, session cookies, X-CSRF-Token values, or sensitive POST payloads. Exploitation requires no authentication and can be performed by any network-reachable client.
Root Cause
The root cause is improper isolation of request-scoped state during the h2c protocol upgrade. Internal buffers holding request headers and body fragments were not consistently cleared or re-initialized between requests handled by the upgraded connection, allowing data from one request context to bleed into another.
Attack Vector
An attacker establishes a network connection to a Tomcat server that has h2c enabled and issues HTTP/1.1 requests with an Upgrade: h2c header. Under concurrent load, the server response stream may include headers and body fragments belonging to other users' requests. Exploitation requires no privileges or user interaction, and the attack vector is network-based against any reachable Tomcat instance with h2c configured.
No public proof-of-concept exploit is available in Exploit-DB or CISA's KEV catalog. See the Apache Tomcat security announcement for technical details.
Detection Methods for CVE-2021-25122
Indicators of Compromise
- Unexpected Upgrade: h2c or HTTP2-Settings headers in HTTP/1.1 request logs from untrusted clients.
- Tomcat access logs showing responses with Content-Length or header sizes inconsistent with the matched request URI.
- User reports of seeing other users' data, session content, or unexpected authentication state in returned pages or API responses.
Detection Strategies
- Inventory all Tomcat deployments and verify version strings against the affected ranges (8.5.0–8.5.61, 9.0.0.M1–9.0.41, 10.0.0-M1–10.0.0).
- Inspect the server.xml Connector configuration for UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" entries that enable h2c on non-TLS connectors.
- Correlate web application firewall logs for anomalous h2c upgrade activity originating from external networks.
Monitoring Recommendations
- Enable verbose Tomcat access logging with request and response header sizes to identify mismatched payloads.
- Monitor for spikes in HTTP/1.1-to-HTTP/2 upgrade attempts, particularly from unauthenticated sources.
- Alert on application-layer errors indicating session or authentication state inconsistencies, which can signal cross-request data exposure.
How to Mitigate CVE-2021-25122
Immediate Actions Required
- Upgrade Apache Tomcat to a fixed version: 10.0.2 or later, 9.0.43 or later, or 8.5.63 or later.
- For Debian-based systems, apply updates from DSA-4891 and the Debian LTS announcement.
- For Oracle products bundling Tomcat, apply the Oracle Critical Patch Update July 2021, October 2021, or January 2022 advisories.
Patch Information
The Apache Tomcat project released fixed builds shortly after disclosure. Administrators should consult the official Tomcat announcement thread and the NetApp security advisory NTAP-20210409-0002 for bundled product guidance. Gentoo users should refer to GLSA 202208-34.
Workarounds
- Disable the HTTP/2 upgrade protocol on cleartext connectors by removing the UpgradeProtocol element from server.xml until patching is complete.
- Terminate TLS at an upstream reverse proxy or load balancer and restrict Tomcat connectors to HTTP/1.1 only when h2c is not required.
- Restrict network exposure of Tomcat connectors to trusted internal networks while remediation is in progress.
# Configuration example: remove h2c UpgradeProtocol from Tomcat server.xml
# Edit $CATALINA_BASE/conf/server.xml and comment out or delete the h2c upgrade entry:
#
# <Connector port="8080" protocol="HTTP/1.1"
# connectionTimeout="20000"
# redirectPort="8443">
# <!-- <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" /> -->
# </Connector>
# Verify the running Tomcat version
$CATALINA_HOME/bin/version.sh | grep "Server version"
# Restart Tomcat after applying changes
systemctl restart tomcat
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


