chore(deps): update dependency org.eclipse.jetty:jetty-server to v12.0.36 [security]

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
org.eclipse.jetty:jetty-server (source)	12.0.5 → 12.0.36

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

---

Eclipse Jetty's ThreadLimitHandler.getRemote() vulnerable to remote DoS attacks

CVE-2024-8184 / GHSA-g8m5-722r-8whq

More information

Details

Impact

Remote DOS attack can cause out of memory

Description

There exists a security vulnerability in Jetty's ThreadLimitHandler.getRemote() which
can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By
repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the
server's memory.

Affected Versions

• Jetty 12.0.0-12.0.8 (Supported)
• Jetty 11.0.0-11.0.23 (EOL)
• Jetty 10.0.0-10.0.23 (EOL)
• Jetty 9.3.12-9.4.55 (EOL)

Patched Versions

• Jetty 12.0.9
• Jetty 11.0.24
• Jetty 10.0.24
• Jetty 9.4.56

Workarounds

Do not use ThreadLimitHandler.
Consider use of QoSHandler instead to artificially limit resource utilization.

References

Jetty 12 - https://github.com/jetty/jetty.project/pull/11723

Severity

• CVSS Score: 5.9 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

References

• https://github.com/jetty/jetty.project/security/advisories/GHSA-g8m5-722r-8whq
• https://nvd.nist.gov/vuln/detail/CVE-2024-8184
• https://github.com/jetty/jetty.project/pull/11723
• https://gitlab.eclipse.org/security/cve-assignement/-/issues/30
• https://lists.debian.org/debian-lts-announce/2025/04/msg00001.html
• https://github.com/advisories/GHSA-g8m5-722r-8whq

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

The Eclipse Jetty Server Artifact has a Gzip request memory leak

CVE-2026-1605 / GHSA-xxh7-fcf3-rj7f

More information

Details

Description (as reported)

There is a memory leak when using GzipHandler in jetty-12.0.30 that can cause off-heap OOMs. This can be used for DoS attacks so I'm reporting this as a vulnerability.

The leak is created by requests where the request is inflated (Content-Encoding: gzip) and the response is not deflated (no Accept-Encoding: gzip). In these conditions, a new inflator will be created by GzipRequest and never released back into GzipRequest.__inflaterPool because gzipRequest.destory() is not called.

In heap dumps one can see thousands of java.util.zip.Inflator objects, which use both Java heaps and native memory. Leaking native memory causes of off-heap OOMs.

Code path in GzipHandler.handle():

1. Line 601: GzipRequest is created when request inflation is needed.
2. Lines 611-616: The callback is only wrapped in GzipResponseAndCallback when both inflation and deflation are needed.
3. Lines 619-625: If the handler accepts the request (returns true), gzipRequest.destroy() is only called in the "request not accepted" path (returns false)

When deflation is needed, GzipResponseAndCallback (lines 102 and 116) properly calls gzipRequest.destroy() in its succeeded() and failed() methods. But this wrapper is only created when deflation is needed.

Possible fix:
The callback should be wrapped whenever a GzipRequest is created, not just when deflation is needed. This ensures gzipRequest.destroy() is always called when the request completes.

Impact

The leak causes the JVM to crash with OOME.

Patches

No patches yet.

Workarounds

Disable GzipHandler.

References

https://github.com/jetty/jetty.project/issues/14260

https://gitlab.eclipse.org/security/cve-assignment/-/issues/79

Severity

• CVSS Score: 7.5 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

• https://github.com/jetty/jetty.project/security/advisories/GHSA-xxh7-fcf3-rj7f
• https://nvd.nist.gov/vuln/detail/CVE-2026-1605
• https://github.com/jetty/jetty.project/issues/14260
• https://gitlab.eclipse.org/security/cve-assignment/-/issues/79
• https://github.com/advisories/GHSA-xxh7-fcf3-rj7f

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Eclipse Jetty: HTTP Authority/Host mismatch

CVE-2026-6790 / GHSA-7p3p-8qv8-m2vh

More information

Details

Summary

Jetty currently accepts HTTP/2 and HTTP/3 requests where the regular
Host header and the pseudo-header :authority
do not match. As a result, the same request can carry two different host identities
through Jetty:

• logic based on HttpURI / Request.getServerName(request) uses :authority
• logic based on raw request headers continues to use Host

This creates a host/authority confusion condition that can break
security assumptions in higher layers.

Jetty already performs an explicit authority/Host consistency check on
the HTTP/1.1 path, but equivalent validation is missing on the HTTP/2
and HTTP/3 paths.

Security Impact

This issue is not inherently remote code execution, but it can become
security-relevant in deployments that rely on the request host for
security-sensitive decisions, including:

• host-based access control
• virtual host isolation
• multi-tenant routing by hostname
• login/logout/callback URL construction
• reverse proxy and forwarded-header trust chains
• auditing, cache keys, and absolute URL generation

Potential consequences include:

• bypass of host-based ACLs
• virtual host or tenant isolation failures
• incorrect or attacker-influenced redirect/callback targets
• inconsistent proxy/downstream interpretation of the original target host
• misleading logs and audit records

Technical Root Cause

1. On the HTTP/2 and HTTP/3 metadata builder paths:

• :authority is parsed separately into authority/URI state
• Host is preserved as a normal request header
• the two values are not compared for consistency

2. On the HTTP/2 and HTTP/3 server entry paths:

• Jetty calls ComplianceUtils.verify(httpCompliance, requestMetaData, listener)
• this verification does not enforce MISMATCHED_AUTHORITY

3. On the HTTP/1.1 path:

• Jetty explicitly checks whether authority and Host match
• mismatches are rejected by default

Relevant Code Locations

HTTP/2 metadata builder:

• jetty-core/jetty-http2/jetty-http2-hpack/src/main/java/org/eclipse/jetty/http2/hpack/internal/MetaDataBuilder.java

HTTP/3 metadata builder:

• jetty-core/jetty-http3/jetty-http3-qpack/src/main/java/org/eclipse/jetty/http3/qpack/internal/metadata/MetaDataBuilder.java

HTTP/2 server entry:

• jetty-core/jetty-http2/jetty-http2-server/src/main/java/org/eclipse/jetty/http2/server/internal/HttpStreamOverHTTP2.java

HTTP/3 server entry:

• jetty-core/jetty-http3/jetty-http3-server/src/main/java/org/eclipse/jetty/http3/server/internal/HttpStreamOverHTTP3.java

Shared HTTP compliance verification:

• jetty-core/jetty-http/src/main/java/org/eclipse/jetty/http/ComplianceUtils.java

HTTP/1.1 authority/Host consistency check:

• jetty-core/jetty-server/src/main/java/org/eclipse/jetty/server/internal/HttpConnection.java

Defined but not enforced on H2/H3:

• jetty-core/jetty-http/src/main/java/org/eclipse/jetty/http/HttpCompliance.java
• violation: MISMATCHED_AUTHORITY

Reproduction

I reproduced this on local Jetty 12.1.9-SNAPSHOT source.

Minimal reproduction steps:

1. Start a Jetty HTTP/2 or HTTP/3 test server.
2. Send a request with:
   • :authority = localhost:
   • Host = evil.example:
3. In the request handler, inspect both:
   • Request.getServerName(request)
   • request.getHeaders().get(HttpHeader.HOST)
4. Observe whether Jetty rejects the request or allows both values to remain visible.
   Observed result:
   • HTTP/2: request is accepted and returns 200
   • HTTP/3: request is accepted and returns 200
   • the server can observe both:
     • serverName=localhost
     • hostHeader=evil.example:

This shows that a single attacker-controlled request can preserve two conflicting host interpretations inside Jetty.

Tests Used

HTTP/2 rejection test:

• org.eclipse.jetty.http2.tests.HTTP2Test#testRejectMismatchedHostHeaderAndAuthority

HTTP/2 exploitability test:

• org.eclipse.jetty.http2.tests.HTTP2Test#testMismatchedHostHeaderAndAuthoritySplitsAuthorityFromHostHeader

HTTP/3 rejection test:

• org.eclipse.jetty.http3.tests.HandlerClientServerTest#testRejectMismatchedHostHeaderAndAuthority

HTTP/3 exploitability test:

• org.eclipse.jetty.http3.tests.HandlerClientServerTest#testMismatchedHostHeaderAndAuthoritySplitsAuthorityFromHostHeader

Observed behavior:

• both rejection tests fail because Jetty returns 200 instead of 400
• both exploitability tests pass, confirming that Jetty exposes different host values to different layers

Project-Internal Evidence of Real Impact

Examples:

• jetty-openid uses Request.getServerName(request) to construct redirect URLs
• jetty-ee11-proxy uses the raw Host header when building Forwarded

This indicates that the issue is not merely theoretical: Jetty’s own
ecosystem already contains code paths where different host sources are
used for different purposes.

Affected Version

Confirmed affected version:

• 12.1.9-SNAPSHOT

Other versions may also be affected if they share the same HTTP/2 /
HTTP/3 request construction and compliance-validation logic. I have
not yet completed a historical version matrix and would recommend
confirming exact affected ranges from Jetty’s branch history.

Suggested Fix

Recommend adding HTTP/2 and HTTP/3 validation equivalent to the
existing HTTP/1.1 authority/Host consistency check:

• if both :authority and regular Host are present
  • normalize and compare them
  • if they do not match, reject the request with 400 Bad Request
  • route the failure through the existing MISMATCHED_AUTHORITY compliance mechanism

Also adding explicit HTTP/2 and HTTP/3 regression coverage for this case.

Disclosure Status

• not publicly disclosed
• no public issue filed
• shared only privately with the Jetty security contacts

Severity

• CVSS Score: 5.3 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

References

• https://github.com/jetty/jetty.project/security/advisories/GHSA-7p3p-8qv8-m2vh
• https://nvd.nist.gov/vuln/detail/CVE-2026-6790
• https://github.com/jetty/jetty.project/issues/14870
• https://github.com/jetty/jetty.project/pull/14871
• https://github.com/jetty/jetty.project/pull/14897
• https://github.com/jetty/jetty.project/pull/14970
• https://github.com/jetty/jetty.project/commit/3e5a4daec196859b8886b6f67b1157dab47cdb6f
• https://github.com/jetty/jetty.project/commit/67ba9e6b39661810123680d9c894e99a7940c73d
• https://github.com/jetty/jetty.project/commit/cbca3076f7c914a232e7a8b22fa95fbf7e67a6cc
• https://github.com/jetty/jetty.project/releases/tag/jetty-12.0.35
• https://github.com/jetty/jetty.project/releases/tag/jetty-12.1.9
• https://gitlab.eclipse.org/security/cve-assignment/-/work_items/99
• https://github.com/advisories/GHSA-7p3p-8qv8-m2vh

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Eclipse Jetty: Cross-Request Leakage for trailers on HTTP/1.1 keep-alive connections

CVE-2026-10051 / GHSA-f4v5-65jj-pcr2

More information

Details

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.

Severity

• CVSS Score: 6.9 / 10 (Medium)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

References

• https://github.com/jetty/jetty.project/security/advisories/GHSA-f4v5-65jj-pcr2
• https://nvd.nist.gov/vuln/detail/CVE-2026-10051
• https://github.com/jetty/jetty.project/pull/15162
• https://github.com/jetty/jetty.project/pull/15163
• https://github.com/jetty/jetty.project/commit/72206b3ea623cf7ed8729b47a83ee628ff10e8eb
• https://github.com/jetty/jetty.project/commit/dc27e8d3ab743fe27935ea2d8c41756eb6c5bae9
• https://github.com/jetty/jetty.project/releases/tag/jetty-12.0.36
• https://github.com/jetty/jetty.project/releases/tag/jetty-12.1.10
• https://gitlab.eclipse.org/security/cve-assignment/-/work_items/119
• https://github.com/advisories/GHSA-f4v5-65jj-pcr2

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.