CVE-2020-17527: Apache Tomcat Information Disclosure Flaw

CVE-2020-17527 Overview

CVE-2020-17527 is an information leakage vulnerability affecting Apache Tomcat's HTTP/2 implementation. During the investigation of bug 64830, it was discovered that Apache Tomcat could re-use an HTTP request header value from the previous stream received on an HTTP/2 connection for the request associated with a subsequent stream. While this behavior would most likely result in an error and closure of the HTTP/2 connection, it creates a potential for sensitive information to leak between requests from different users sharing the same HTTP/2 connection.

Critical Impact

HTTP request header values from one user's request may be inadvertently applied to another user's subsequent request on a shared HTTP/2 connection, potentially exposing sensitive authentication tokens, session identifiers, or other confidential header data.

Affected Products

• Apache Tomcat 10.0.0-M1 to 10.0.0-M9
• Apache Tomcat 9.0.0-M1 to 9.0.39
• Apache Tomcat 8.5.0 to 8.5.59
• NetApp Element Plug-in for vCenter Server
• NetApp OnCommand System Manager
• Debian Linux 9.0 and 10.0
• Oracle Blockchain Platform
• Oracle Communications Cloud Native Core Binding Support Function 1.10.0
• Oracle Communications Cloud Native Core Policy 1.14.0
• Oracle Communications Instant Messaging Server 10.0.1.5.0
• Oracle Instantis EnterpriseTrack 17.1, 17.2, 17.3
• Oracle MySQL Enterprise Monitor
• Oracle SD-WAN Edge 9.0
• Oracle Workload Manager 18c, 19c

Discovery Timeline

• December 3, 2020 - CVE-2020-17527 published to NVD
• November 21, 2024 - Last updated in NVD database

Technical Details for CVE-2020-17527

Vulnerability Analysis

The vulnerability resides in Apache Tomcat's HTTP/2 protocol implementation, specifically in how it manages request header state between successive streams on a single connection. HTTP/2 uses multiplexed streams to handle multiple concurrent requests over a single TCP connection, requiring careful state management to ensure data isolation between streams.

In affected versions, the request header recycling mechanism fails to properly clear header values when transitioning between streams. This improper resource reuse means that header data from a completed request stream may persist and be erroneously applied to the next stream's request on the same connection. The vulnerability is classified under CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor).

The network-accessible nature of the vulnerability means any client capable of establishing HTTP/2 connections to an affected Tomcat server could potentially trigger or exploit this condition. While the immediate result is typically a protocol error causing connection termination, race conditions in stream processing could allow header data to be processed before the error is detected.

Root Cause

The root cause stems from improper state management in the HTTP/2 stream handling code. When Apache Tomcat processes HTTP/2 requests, it maintains internal data structures to track header information for each stream. The vulnerability occurs because these data structures are not completely reset when one stream ends and another begins, leading to data contamination between streams. This is a classic example of an improper resource cleanup issue where recycled objects retain stale data from previous operations.

Attack Vector

An attacker could potentially exploit this vulnerability by establishing an HTTP/2 connection to a vulnerable Tomcat server and sending crafted requests designed to maximize the chances of header leakage. The attack scenario is primarily passive in nature—the attacker may receive headers intended for another user who happens to use the same HTTP/2 connection.

In multi-tenant environments or scenarios where a reverse proxy multiplexes multiple users onto shared backend connections, the impact could be more severe. Leaked headers might include Authorization tokens, Cookie values, custom session identifiers, or other sensitive authentication and tracking data.

The typical exploitation flow involves:

1. Multiple users connecting through an HTTP/2-enabled path to the vulnerable Tomcat server
2. Rapid stream creation and completion triggering the race condition
3. Header values from User A's request being applied to User B's subsequent stream
4. User B potentially receiving error responses containing User A's header information, or User A's headers being logged in association with User B's request

Detection Methods for CVE-2020-17527

Indicators of Compromise

• Unexpected HTTP error responses on HTTP/2 connections, particularly protocol-level errors indicating malformed requests
• Application logs showing header values that do not match the expected request context or user session
• Increased HTTP/2 connection resets (RST_STREAM frames) in network traffic analysis
• User reports of receiving responses intended for other users or authentication errors on previously valid sessions

Detection Strategies

• Monitor Tomcat access logs for anomalous header patterns, particularly Authorization or Cookie headers appearing on requests where they shouldn't exist
• Implement network-level HTTP/2 traffic analysis to detect unusual stream reset patterns or protocol errors
• Deploy application-layer monitoring to correlate request headers with expected user session data
• Review Tomcat error logs for StreamException or header-related processing errors in the HTTP/2 upgrade handler

Monitoring Recommendations

• Enable detailed HTTP/2 debugging in development environments to capture stream-level processing details
• Configure centralized logging aggregation to correlate HTTP/2 connection events across multiple Tomcat instances
• Implement runtime application self-protection (RASP) solutions to detect header manipulation anomalies
• Use SentinelOne Singularity Platform for endpoint and workload protection to identify exploitation attempts and unusual process behavior

How to Mitigate CVE-2020-17527

Immediate Actions Required

• Upgrade Apache Tomcat immediately: version 10.0.0-M10 or later for the 10.x branch, version 9.0.40 or later for the 9.x branch, and version 8.5.60 or later for the 8.5.x branch
• If immediate patching is not possible, consider disabling HTTP/2 support temporarily by removing or commenting out the UpgradeProtocol configuration for HTTP/2 in server.xml
• Review access logs for any signs of information leakage that may have occurred prior to patching
• Notify security teams and conduct risk assessment for environments where sensitive header data is transmitted

Patch Information

Apache has released patched versions addressing this vulnerability. Organizations should upgrade to the following minimum versions:

• Apache Tomcat 10.x: Upgrade to 10.0.0-M10 or later
• Apache Tomcat 9.x: Upgrade to 9.0.40 or later
• Apache Tomcat 8.5.x: Upgrade to 8.5.60 or later

For detailed patch information, consult the Apache Tomcat Announcement Thread and the Debian Security Advisory DSA-4835. Oracle customers should also review the relevant Oracle CPU April 2021 and subsequent security updates for affected Oracle products.

Workarounds

• Disable HTTP/2 support by removing the UpgradeProtocol element for org.apache.coyote.http2.Http2Protocol from the Tomcat server.xml configuration
• Configure reverse proxies to terminate HTTP/2 connections and communicate with Tomcat backends using HTTP/1.1 only
• Implement network segmentation to limit exposure of vulnerable Tomcat instances to untrusted networks
• Deploy web application firewalls (WAFs) to monitor and filter HTTP/2 traffic for anomalous patterns

# Disable HTTP/2 in Tomcat server.xml
# Remove or comment out the following line from your Connector configuration:
# <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" />

# Example secure Connector configuration using HTTP/1.1 only:
# <Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
#            maxThreads="150" SSLEnabled="true">
#     <SSLHostConfig>
#         <Certificate certificateKeystoreFile="conf/localhost-rsa.jks"
#                      type="RSA" />
#     </SSLHostConfig>
# </Connector>