GHSA-86wm-rrjm-8wh8 BIT-kafka-2020-27218 BIT-spark-2020-27218 CVE-2020-27218

Buffer not correctly recycled in Gzip Request inflation

Medium Maven

Severity: 4.8 / 10; Medium · CVSS 3.1
Exploit chance (EPSS): 8.28%; Chance of exploitation in the next 30 days. Higher than 94.92% of scored vulnerabilities.
Known exploited: No; Not in CISA's catalog
Weakness: CWE-226 Sensitive Information in Resource Not Removed Before Reuse
Fix: 9.4.35.v20201120; Upgrade org.eclipse.jetty:jetty-server to this version or later

Description

Impact

If GZIP request body inflation is enabled and requests from different clients are multiplexed onto a single connection and if an attacker can send a request with a body that is received entirely by not consumed by the application, then a subsequent request on the same connection will see that body prepended to it's body.

The attacker will not see any data, but may inject data into the body of the subsequent request

CVE score is 4.8 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L

Workarounds

The problem can be worked around by either:

Disabling compressed request body inflation by GzipHandler.
By always fully consuming the request content before sending a response.
By adding a Connection: close to any response where the servlet does not fully consume request content.

Affected versions

Maven

Package	Vulnerable	Fixed in
org.eclipse.jetty:jetty-server	`>= 9.4.0, < 9.4.35.v20201120`	`9.4.35.v20201120`

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

org.eclipse.jetty:jetty-server Maven → `9.4.35.v20201120`

maven

<dependency><groupId>org.eclipse.jetty</groupId><artifactId>jetty-server</artifactId><version>9.4.35.v20201120</version></dependency>

gradle

implementation("org.eclipse.jetty:jetty-server:9.4.35.v20201120")

Severity breakdown

CVSS 3.1 4.8

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L

Attack vector: Network
Attack complexity: High
Privileges required: None
User interaction: None
Scope: Unchanged
Confidentiality: None
Integrity: Low
Availability: Low

Weakness

CWE-226: Sensitive Information in Resource Not Removed Before Reuse

The product releases a resource such as memory or a file so that it can be made available for reuse, but it does not clear or "zeroize" the information contained in the resource before the product performs a critical state transition or makes the resource available for reuse by other entities.

How to prevent it

Architecture and Design, Implementation: During critical state transitions, information not needed in the next state should be removed or overwritten with fixed patterns (such as all 0's) or random data, before the transition to the next state.
Architecture and Design, Implementation: When releasing, de-allocating, or deleting a resource, overwrite its data and relevant metadata with fixed patterns or random data. Be cautious about complex resource types whose underlying representation might be non-contiguous or change at a low level, such as how a file might be split into different chunks on a file system, even though "logical" file positions are contiguous at the application layer. Such resource types might require invocation of special modes or APIs to tell the underlying operating system to perform the necessary clearing, such as SDelete (Secure Delete) on Windows, although the appropriate functionality might not be available at the application layer.

References

Advisories

nvd.nist.gov/vuln/detail/CVE-2020-27218

Packages

github.com/eclipse/jetty.project

Timeline

Dec 2, 2020 Published
Jul 8, 2026 Last updated by the source
Oct 31, 2026 Latest EPSS score

Advisory	Severity	Why it's related
GHSA-7p3p-8qv8-m2vh Eclipse Jetty: HTTP Authority/Host mismatch	Medium	Also affects org.eclipse.jetty:jetty-server
GHSA-f4v5-65jj-pcr2 Eclipse Jetty: Cross-Request Leakage for trailers on HTTP/1.1 keep-alive connections	High	Also affects org.eclipse.jetty:jetty-server
GHSA-9299-c6m4-mjhc Eclipse Jetty: DoS attack triggering OutOfMemory with 100-Continue requests	High	Also affects org.eclipse.jetty:jetty-server
GHSA-xxh7-fcf3-rj7f The Eclipse Jetty Server Artifact has a Gzip request memory leak	High	Also affects org.eclipse.jetty:jetty-server
GHSA-q4rv-gq96-w7c5 UNSUPPORTED WHEN ASSIGNED GzipHandler causes part of request body to be seen as request body of a separate request	High	Also affects org.eclipse.jetty:jetty-server
GHSA-g8m5-722r-8whq Eclipse Jetty's ThreadLimitHandler.getRemote() vulnerable to remote DoS attacks	Medium	Also affects org.eclipse.jetty:jetty-server
GHSA-p26g-97m4-6q7c Eclipse Jetty's cookie parsing of quoted values can exfiltrate values from other cookies	Medium	Also affects org.eclipse.jetty:jetty-server
GHSA-qw69-rqj8-6qw8 OutOfMemoryError for large multipart without filename in Eclipse Jetty	Medium	Also affects org.eclipse.jetty:jetty-server

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor