[GHSA-355h-qmc2-wpwf] Jetty has HTTP Request Smuggling via Chunked Extension Quoted-String Parsing

[jhy]

Updates

• Affected products

Comments
This had 9.4.60 listed as a patched version. But there is no such version per https://repo1.maven.org/maven2/org/eclipse/jetty/jetty-distribution/ . So I removed it from the 9 Patched Versions field -- not sure if that's the clearest way to do that.

https://jetty.org/download.html has latest on the 9 series as "9.4.58.v20250814 (EOL)"

[github]

Hi there @olamy! 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

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Updates the GHSA record for Jetty request smuggling to remove a non-existent patched version in the 9.x line and represent the end of affected versions appropriately.

Changes:

• Replaced fixed: 9.4.60 with last_affected: 9.4.59 for the 9.4.x range.
• Removed database_specific.last_known_affected_version_range.
• Bumped the modified timestamp.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The PR description notes Jetty 9’s latest release is 9.4.58... (EOL), but the advisory now marks last_affected as 9.4.59. Please reconcile this by setting last_affected to the actual last released vulnerable version (or using the project’s exact version string convention, e.g., including the .vYYYYMMDD suffix if that’s what consumers expect) so the affected range doesn’t reference a version that may not exist.

[Copilot]

Removing database_specific.last_known_affected_version_range may be a breaking change for downstream consumers/tools that rely on that field (even if the same information is representable via events). If this repo’s advisories commonly include last_known_affected_version_range, consider keeping database_specific and updating it to match the new representation to preserve compatibility.

Suggested change

	]
	],
	"database_specific": {
	"last_known_affected_version_range": "<= 9.4.59"
	}

[olamy]

@jhy Thanks for this.
There is such a version, but not in Maven Central.
For more details, please have a look at this page https://jetty.org/security.html
And especially the link to https://webtide.com/end-of-life/
So as a Jetty committer I would reject such change

[shelbyc]

@olamy I agree with @jhy's proposed change. The GitHub Advisory Database has encountered this situation before with other advisories in the Maven ecosystem, and in the past, my teammates and I have avoided recommending that users upgrade to commercial-only releases.

At #5662 (comment), I explained that commercial-only releases don't appear on Maven or on GitHub, essentially leaving users without an open-source path for upgrading. And we've been resistant to recommending commercial vulnerability remediation solutions to avoid the GitHub Advisory Database becoming an advertising platform.

As the person who published the repo advisory for GHSA-355h-qmc2-wpwf, you still control the content and any changes made to the global advisory won't change that. But typical practice for my curator colleagues and me would be to remove patched versions where the only patch available is provided commercially.

[joakime]

@shelbyc it would be nice if the advisory database supported flagging EOL versions (which this discussion is ultimately about), followed up by dependabot also highlighting EOL versions (which other dependency tooling already does).