GHSA-x3rh-m7vp-35f2 CVE-2019-17638

Operation on a Resource after Expiration or Release in Jetty Server

Critical Maven

Severity: 9.4 / 10; Critical · CVSS 3.1
Exploit chance (EPSS): 11.14%; Chance of exploitation in the next 30 days. Higher than 95.94% of scored vulnerabilities.
Known exploited: No; Not in CISA's catalog
Weakness: CWE-672 Operation on a Resource after Expiration or Release; CWE-675 Multiple Operations on Resource in Single-Operation Context
Fix: 9.4.30.v20200611; Upgrade org.eclipse.jetty:jetty-server to this version or later

Description

In Eclipse Jetty, versions 9.4.27.v20200227 to 9.4.29.v20200521, in case of too large response headers, Jetty throws an exception to produce an HTTP 431 error. When this happens, the ByteBuffer containing the HTTP response headers is released back to the ByteBufferPool twice. Because of this double release, two threads can acquire the same ByteBuffer from the pool and while thread1 is about to use the ByteBuffer to write response1 data, thread2 fills the ByteBuffer with response2 data. Thread1 then proceeds to write the buffer that now contains response2 data. This results in client1, which issued request1 and expects responses, to see response2 which could contain sensitive data belonging to client2 (HTTP session ids, authentication credentials, etc.).

Affected versions

Maven

Package	Vulnerable	Fixed in
org.eclipse.jetty:jetty-server	`>= 9.4.27, < 9.4.30.v20200611`	`9.4.30.v20200611`

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.30.v20200611`

maven

<dependency><groupId>org.eclipse.jetty</groupId><artifactId>jetty-server</artifactId><version>9.4.30.v20200611</version></dependency>

gradle

implementation("org.eclipse.jetty:jetty-server:9.4.30.v20200611")

Severity breakdown

CVSS 3.1 9.4

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

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

Weakness

CWE-672: Operation on a Resource after Expiration or Release

The product uses, accesses, or otherwise operates on a resource after that resource has been expired, released, or revoked.

CWE-675: Multiple Operations on Resource in Single-Operation Context

The product performs the same operation on a resource two or more times, when the operation should only be applied once.

References

Advisories

nvd.nist.gov/vuln/detail/CVE-2019-17638

Timeline

Aug 5, 2020 Published
Mar 14, 2024 Last updated by the source
Nov 1, 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