Eclipse Jetty: Cross-Request Leakage for trailers on HTTP/1.1 keep-alive connectionsGHSA-f4v5-65jj-pcr2
Fix: jetty/jetty.project#15162GHSA-f4v5-65jj-pcr2 is a Information Exposure vulnerability in org.eclipse.jetty:jetty-server. A fix is available for org.eclipse.jetty:jetty-server — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-f4v5-65jj-pcr2.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
org.eclipse.jetty:jetty-server☕org.eclipse.jetty:jetty-serverReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
Description
FINDING — MEDIUM (HTTP/1.1 keep-alive connections with trailers) HttpConnection._trailers Cross-Request Leakage (Never Reset Between Requests)
Location: jetty-core/jetty-server/src/main/java/org/eclipse/jetty/server/internal/ HttpConnection.java:107, 1157-1161, 1170
Detail: _trailers (line 107) is a connection-scoped HttpFields.Mutable field. parsedTrailer() (line 1157) populates it when request N carries HTTP trailers. messageComplete() (line 1170) checks "if (_trailers != null)" — evaluates true from request N's data — and stamps it onto request N+1.
Grep confirms: ZERO occurrences of "_trailers = null" in entire HttpConnection.java.
Scenario: Request N: POST /upload (trailers: X-Checksum: abc123) Request N+1: GET /data (no trailers) app: request.getTrailers() on N+1 → returns {X-Checksum: abc123} ← STALE
Application logic branching on getTrailers() != null produces incorrect behavior. Not cross-connection (same keep-alive connection only).
More dangerous scenario: TOCTOU — trailer passes check, target swapped before use.
Workarounds
Do not rely on HTTP request trailers for security-sensitive logic, or disable persistent connections by closing the connection after each HTTP/1.1 request.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | org.eclipse.jetty:jetty-server | ≥ 12.0.0&&< 12.0.36 | 12.0.36org.eclipse.jetty:jetty-server:12.0.36 |
| ☕Maven | org.eclipse.jetty:jetty-server | ≥ 12.1.0&&< 12.1.10 | 12.1.10org.eclipse.jetty:jetty-server:12.1.10 |
Affected Products
jettyeclipseDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.eclipse.jetty:jetty-server, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update org.eclipse.jetty:jetty-server to 12.0.36 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-f4v5-65jj-pcr2 is resolved across your whole dependency graph.
Workarounds
Assume what was exposed is already known: rotate any credential, token or key that the affected component could return, restrict the endpoint to callers that genuinely need it, and strip sensitive fields from responses and error output at the boundary rather than relying on the client not to read them.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
Moderate: This information disclosure flaw in Eclipse Jetty allows HTTP/1.1 trailers from a previous request to be retained and subsequently exposed to other requests sharing the same connection. This could lead to unintended disclosure of sensitive information in Red Hat products utilizing Jetty, such as Red Hat AMQ…
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.Source: Red Hat security advisory for GHSA-f4v5-65jj-pcr2 (CC BY 4.0)
| Product | Fixed in | Advisory |
|---|---|---|
| Red Hat AMQ Broker 7.13.6 | jetty-server | RHSA-2026:66545 |
| Red Hat AMQ Broker 7.14.1 | jetty-server | RHSA-2026:66488 |
| Red Hat build of Apache Camel 4.18.4 for Spring Boot 3.5.16 | jetty-server | RHSA-2026:71675 |
| Red Hat Satellite 6.16 for RHEL 8 | el8/openvox-server:0:8.15.2-1.el8sat | RHSA-2026:63327 |
| Red Hat Satellite 6.17 for RHEL 9 | ansible-core-1:2.16.19-1.el9sat | RHSA-2026:63387 |
| Red Hat Satellite 6.18 for RHEL 9 | el8/openvox-server:0:8.15.2-1.el9sat | RHSA-2026:63386 |
| Red Hat Satellite 6.19 for RHEL 9 | el8/openvox-server:0:8.15.2-1.el9sat | RHSA-2026:63385 |
| Streams for Apache Kafka 3.2.1 | jetty-server | RHSA-2026:54435 |
Frequently Asked Questions
Is GHSA-f4v5-65jj-pcr2 in your dependencies?
Find it across Maven, including transitive dependencies.