[GHSA-qh8g-58pp-2wxh] Eclipse Jetty URI parsing of invalid authority

[levpachmanov]

Updates

• Affected products
• CVSS v3

Comments
The fix for this advisory (commit db8bb7a8631aafc7897032b133a5b425854e5841, PR jetty/jetty.project#12532, "Fix CVE-2024-6763") was independently backported to each maintenance branch, not fixed only at 12.0.12.

Verified via git tag --contains db8bb7a8631aafc7897032b133a5b425854e5841 against jetty/jetty.project, and independently by diffing HttpURI.java from each release's sources jar on Maven Central against the pre/post-fix code (presence of Violation.USER_INFO / isUnreservedPctEncodedOrSubDelim and the hardened authority-state validation logic).

Per-branch first-fixed versions

Branch	First fixed version	Confirmed still vulnerable
9.4.x	9.4.57.v20241219	9.4.51.v20230217, 9.4.53.v20231009, 9.4.56.v20240826
10.0.x	10.0.26	10.0.19, 10.0.22
11.0.x	11.0.26	11.0.23, 11.0.24
12.0.x	12.0.12	(as currently stated)

Suggested vulnerable_version_range entries

Replace the single range with four, one per branch:

• >= 7.0.0, < 9.4.57.v20241219 → patched 9.4.57.v20241219
• >= 10.0.0, < 10.0.26 → patched 10.0.26
• >= 11.0.0, < 11.0.26 → patched 11.0.26
• >= 12.0.0, <= 12.0.11 → patched 12.0.12

Why this matters

The current single range >= 7.0.0, <= 12.0.11 implies every 9.4.x/10.0.x/11.0.x release up to that point remains vulnerable, but releases on those branches at or after the versions above already contain the fix. Recommend splitting into the four ranges above so scanners don't flag already-patched maintenance-branch releases.

[github]

Hi there @joakime! A community member has suggested an improvement to your security advisory. If approved, this change will affect the global advisory listed at github.com/advisories. It will not affect the version listed in your project repository.

This change will be reviewed by our Security Curation Team. If you have thoughts or feedback, please share them in a comment here! If this PR has already been closed, you can start a new community contribution for this advisory

[joakime]

Reject.

This is not fixed in the EOL releases of Jetty 9, Jetty 10, or Jetty 11.
It CANNOT be fixed in Jetty 9, Jetty 10, or Jetty 11, as they are on older RFCs with regards to HTTP that require the authority to be present, even in the bad/confusing/illegal ways.
Only Jetty 12 can have this fix, as it's on the latest RFC that removes support for the authority.

See past PRs on here for details.

• https://github.com/github/advisory-database/pulls?q=is%3Apr+GHSA-qh8g-58pp-2wxh
• [GHSA-qh8g-58pp-2wxh] Eclipse Jetty URI parsing of invalid authority #6537
• [GHSA-qh8g-58pp-2wxh] Eclipse Jetty URI parsing of invalid authority #5210
• [GHSA-qh8g-58pp-2wxh] Eclipse Jetty URI parsing of invalid authority #5222
• [GHSA-qh8g-58pp-2wxh] Eclipse Jetty URI parsing of invalid authority #5475
• [GHSA-qh8g-58pp-2wxh] Eclipse Jetty URI parsing of invalid authority #5496
• [GHSA-qh8g-58pp-2wxh] Eclipse Jetty URI parsing of invalid authority #5507

[levpachmanov]

Thanks for the detailed pointers @joakime — I read through #5210, #5222, #5475, #5496, #5507 and the Eclipse CNA thread before writing this.

Two of your points I fully accept:

• CVE-2024-6763 is Eclipse-CNA-managed, and the CVE record listing only 12.x is not GitHub's to change.
• Jetty 9, 10 and 11 are EOL. They should ideally be flagged as such.

Neither of those is what this PR is about, though. A GHSA vulnerable_version_range is GitHub's own statement about which released artifacts contain the fix. Right now it says every 9.4.x, 10.0.x and 11.0.x release is vulnerable, and that does not match the artifacts published on Maven Central.

I'd also like to correct my own PR before anything else: I had the 10.x and 11.x numbers wrong. The fix landed in 10.0.25 / 11.0.25, not .26 — HttpURI.java is byte-identical between .25 and .26 on both branches. I've corrected the ranges (see below). My original "verified via git tag --contains" reasoning was also not sound for 10.x/11.x: db8bb7a is a 9.4.x commit that only reaches those tags via merge-forward. The evidence below is based on the published artifacts instead.

---

What the released artifacts actually do

I took the jetty-http binary jars straight from Maven Central and parsed the CVE's own class of input through HttpURI. No source reading, no inference — just what ships.

input	9.4.56	9.4.57	10.0.24	10.0.25	11.0.24	11.0.25	12.0.11	12.0.12
http://127.0.0.1;example.com/	accepts	rejects	accepts	rejects	accepts	rejects	accepts	accepts
http://127.0.0.1#example.com/	accepts	rejects	accepts	rejects	accepts	rejects	accepts	rejects
http://exam ple.com/	accepts	rejects	accepts	rejects	accepts	rejects	accepts	rejects
http://exa%zzmple.com/	accepts	rejects	accepts	rejects	accepts	rejects	accepts	rejects
http://foo[::1]/	accepts	rejects	accepts	rejects	accepts	rejects	accepts	rejects

"accepts" = returns a host; "rejects" = IllegalArgumentException: Bad authority.

On every vector that 12.0.12 hardened, 9.4.57 / 10.0.25 / 11.0.25 behave the same. On 127.0.0.1;example.com the maintenance branches are actually stricter than 12.0.12, because the backport added an explicit case '#': case ';': throw new IllegalArgumentException("Bad authority") in the AUTHORITY state that 12.0.12 does not have.

On "a narrowed subset"

I looked specifically for what was narrowed, and the only two behavioural differences I could find run in the other direction:

• http://host:12ab/ — 12.0.12 throws IllegalArgumentException; 9.4/10/11 throw NumberFormatException. Since NumberFormatException extends IllegalArgumentException, the caller-visible contract is identical.
• http://user@host@evil.com/ — 12.0.12 accepts it (relaxed, recorded as a USER_INFO violation); 9.4.57 / 10.0.25 / 11.0.25 reject it.

If there's a concrete input that 12.0.12 rejects and 9.4.57/10.0.25/11.0.25 accept, I'd genuinely like to have it — that would settle this immediately and I'll close the PR myself.

On the RFC argument

they are on older RFCs with regards to HTTP that require the authority to be present, even in the bad/confusing/illegal ways

I think this is about the deprecation of userinfo (RFC 9110 §4.2.4), which is indeed a 12.x-only move. But CVE-2024-6763 is about accepting invalid characters in the authority, which is an RFC 3986 reg-name grammar question that hasn't changed between those RFC levels.

And the backports are consistent with that reading: they keep userinfo fully working — recording Violation.USER_INFO rather than rejecting — while adding the grammar validation. That's the same design as 12.0.12, which is why it was possible to backport at all.

Provenance

• 9.4.x: Fix CVE-2024-6763 jetty/jetty.project#12532, "Fix CVE-2024-6763", authored and merged by @gregw, released in 9.4.57.v20241219.
• 10.x / 11.x: Introduce UriCompliance.USER_INFO to Jetty 10.0.x jetty/jetty.project#12874, released in 10.0.25 / 11.0.25 (both published 2025-03-13).

I understand the position that this was a sponsored backport for EOL lines and that the Jetty server was never the exposed surface here. But these are public Maven Central artifacts, and every scanner reading this advisory currently reports them as vulnerable — including releases where the code demonstrably rejects the malformed authorities.

[joakime]

Your analysis is looking at a single commit and declaring it fixed.
That commit changes ONLY HttpURI behavior, not how HttpURI is used by the server, which is radically different in Jetty 9/10/11 vs Jetty 12.
The reason you don't see more on Jetty 12 to address this CVE is because of thousands of prior commits that change the interactions between the raw HTTP request (HTTP/1, HTTP/2, HTTP/3, proxy, and dozens of other spec). Those prior changes do not exist on Jetty 9/10/11.
Don't be fooled by your AI, this is NOT addressed on 9/10/11 for Jetty Server and Jetty Client usages.
It is ONLY fixed for direct usage of HttpURI by your own code.

[levpachmanov]

@joakime thanks for taking the time to go through this - genuinely appreciated.

At Seal we aim to give our customers the most accurate picture we can of what's actually exploitable, so an example or PoC demonstrating the vulnerability on 9.4.57 / 10.0.25 / 11.0.25 but not on 12.0.12 would be very helpful for me to understand this vulnerability.