CVE-2020-27218 Overview
CVE-2020-27218 is a data injection vulnerability in Eclipse Jetty affecting versions 9.4.0.RC0 through 9.4.34.v20201102, 10.0.0.alpha0 through 10.0.0.beta2, and 11.0.0.alpha0 through 11.0.0.beta2. When GZIP request body inflation is enabled and requests from different clients are multiplexed onto a single connection, an attacker can exploit improper handling of unconsumed request bodies. If an attacker sends a request with a body that is received entirely but not consumed by the application, subsequent requests on the same connection will have that body prepended to their own. While the attacker cannot exfiltrate data through this vulnerability, they can inject arbitrary data into the body of subsequent requests from other users.
Critical Impact
Attackers can inject malicious data into HTTP request bodies of other users sharing the same connection, potentially leading to data integrity issues, request manipulation, and exploitation of downstream application logic.
Affected Products
- Eclipse Jetty 9.4.0.RC0 to 9.4.34.v20201102
- Eclipse Jetty 10.0.0.alpha0 to 10.0.0.beta2
- Eclipse Jetty 11.0.0.alpha0 to 11.0.0.beta2
- NetApp OnCommand System Manager
- NetApp Snap Creator Framework
- Oracle Blockchain Platform
- Oracle Communications Converged Application Server - Service Controller 6.2
- Oracle Communications Offline Mediation Controller 12.0.0.3.0
- Oracle Communications Pricing Design Center 12.0.0.3.0
- Oracle Communications Services Gatekeeper 7.0
- Oracle Communications Session Route Manager
- Oracle FLEXCUBE Private Banking 12.0.0 and 12.1.0
- Oracle Hyperion Infrastructure Technology 11.1.2.6.0
- Oracle REST Data Services
- Oracle Retail EFTLink 20.0.0
- Oracle Siebel Core - Automation
- Apache Kafka 2.7.0
- Apache Spark 2.4.8 and 3.0.3
- Debian Linux 10.0
Discovery Timeline
- 2020-11-28 - CVE-2020-27218 published to NVD
- 2024-11-21 - Last updated in NVD database
Technical Details for CVE-2020-27218
Vulnerability Analysis
This vulnerability is classified under CWE-226 (Sensitive Information in Resource Not Removed Before Reuse). The flaw exists in Jetty's GZIP request body inflation mechanism when handling multiplexed HTTP connections. The core issue stems from improper cleanup of request body data when a request is received but its body is not fully consumed by the application.
In typical HTTP/2 or HTTP/1.1 persistent connection scenarios, multiple client requests can be multiplexed over a single server connection. When GZIP body inflation is enabled, Jetty decompresses incoming request bodies on-the-fly. However, if the application does not fully read the decompressed body, remnant data remains in the connection's internal buffers. This data is then incorrectly prepended to the next request that arrives on the same connection, regardless of which client sent it.
The attack requires specific conditions: GZIP request body inflation must be enabled, connection multiplexing must be in use, and the application must not consume request bodies in certain scenarios.
Root Cause
The root cause is improper resource cleanup in Jetty's GZIP inflation handler. When a request body is received and decompressed but not fully consumed by the application, the internal buffer state is not properly reset before processing the next request. This violates the principle that each HTTP request should be processed in complete isolation from others on shared connections.
The issue specifically manifests in the GzipHandler class when handling inflated content that spans multiple requests. The buffer containing the unconsumed inflated data persists and becomes visible to subsequent requests.
Attack Vector
The attack is network-based and requires specific conditions to exploit. An attacker must send a crafted request with a GZIP-compressed body to a vulnerable Jetty server where the application does not consume the request body. The attacker times their request so that a subsequent legitimate user's request arrives on the same multiplexed connection.
The attack scenario involves the following sequence: First, the attacker sends a POST request with a malicious payload compressed with GZIP encoding. The application receives the request but does not read the body (perhaps because the endpoint doesn't expect a body, or an error occurs before body processing). When the next user sends a request on the same connection, the attacker's unconsumed body data is prepended to the legitimate user's request body.
This could allow an attacker to inject form parameters, JSON fields, or other data structures into another user's request, potentially bypassing security controls or corrupting application state.
Detection Methods for CVE-2020-27218
Indicators of Compromise
- Unexpected data appearing in HTTP request bodies that doesn't match client-sent content
- Application errors or exceptions related to malformed request body parsing
- Log entries showing requests with unexpected content-length mismatches
- Anomalous GZIP-encoded requests to endpoints that don't typically receive compressed bodies
Detection Strategies
- Monitor application logs for request body parsing errors or unexpected data format exceptions
- Implement request integrity checks that validate expected request body structure before processing
- Deploy network monitoring to detect unusual patterns of GZIP-encoded requests
- Use application-level logging to track request body sizes and content hashes for anomaly detection
Monitoring Recommendations
- Configure Jetty access logs to capture request body size and encoding information
- Implement alerting on sudden increases in request body parsing failures
- Monitor connection multiplexing patterns for unusual request sequences
- Review application logs for data integrity violations that could indicate injection attacks
How to Mitigate CVE-2020-27218
Immediate Actions Required
- Upgrade Eclipse Jetty to version 9.4.35.v20201120 or later for the 9.4.x branch
- Upgrade to Jetty 10.0.0.beta3 or later for the 10.x branch
- Upgrade to Jetty 11.0.0.beta3 or later for the 11.x branch
- Review dependent products (Oracle, NetApp, Apache) for vendor-specific patches
- If immediate patching is not possible, consider disabling GZIP request body inflation as a temporary mitigation
Patch Information
Eclipse has released patched versions addressing this vulnerability. The fix ensures proper cleanup of inflated body buffers between requests on multiplexed connections. Patches are available through the official Eclipse Bug Report #568892 and the GitHub Security Advisory GHSA-86wm-rrjm-8wh8.
Oracle has addressed this vulnerability in multiple Critical Patch Updates including April 2021, July 2021, October 2021, and April 2022. NetApp has also issued security advisories for affected products.
Workarounds
- Disable GZIP request body inflation by removing or disabling the GzipHandler for request bodies if not required by your application
- Ensure all application endpoints fully consume request bodies, even if the content is not needed
- Implement request body size limits to reduce the potential impact of data injection
- Consider using separate connection pools for different security contexts to limit cross-user contamination
# Jetty XML configuration to disable GZIP request body inflation
# Add to jetty.xml or jetty-gzip.xml
# Option 1: Disable GzipHandler entirely if not needed
# Remove or comment out the GzipHandler configuration
# Option 2: Configure GzipHandler for responses only (disable request inflation)
# In jetty-gzip.xml, ensure inflateBufferSize is set to -1 or remove request handling
# <Set name="inflateBufferSize">-1</Set>
# Verify Jetty version after upgrade
java -jar start.jar --version
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

