Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
11.0.299.4.6012.0.3312.1.710.0.28· Vendor fix available
Issue
(as reported) Jetty incorrectly parses quoted strings in HTTP/1.1 chunked transfer encoding extension values, enabling request smuggling attacks. Background This vulnerability is a new variant discovered while researching the "Funky Chunks" HTTP request smuggling techniques: - https://w4ke.info/2025/06/18/funky-chunks.html - https://w4ke.info/2025/10/29/funky-chunks-2.html The original research tested various chunk extension parsing differentials but did not test quoted-string handling within extension values. Technical Details RFC 9112 Section 7.1.1 defines chunked transfer encoding: RFC 9110 Section 5.6.4 defines quoted-string: A quoted-string continues until the closing DQUOTE, and \r\n sequences are not permitted within the quotes. Vulnerability Jetty terminates chunk header parsing at \r\n inside quoted strings instead of treating this as an error. Expected (RFC compliant): Actual (jetty): Proof of Concept Result: Server returns 2 HTTP responses from a single TCP…
Recommended action: Upgrade to 12.1.7, 12.0.33, 11.0.29 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Jetty URI parser has some key differences compared to other common parsers when evaluating invalid or unusual URIs. Specifically: Invalid Scheme | URI | Jetty | uri-js (nodejs) | node-url(nodejs) | |---|---|---| --- | | https://vulndetector.com/path | scheme=http| scheme=https | invalid URI | Improper IPv4 mapped IPv6 | URI | Jetty | System.Uri(CSharp) | curl(C) | |---|---|---| --- | | http://[0:0:0:0:0:ffff:127.0.0.1] | invalid | host=[::ffff:127.0.0.1] | host=[::ffff:127.0.0.1] | | http://[::ffff:255.255.0.0] | invalid | host=[::ffff:255.255.0.0] | host=[::ffff:255.255.0.0] | Incorrect IPv6 delimeter priority | URI | Jetty | urllib3(python) | furl(python) | Spring | chromium | |---|---|---| --- |---|---| | http://[normal.com@]vulndetector.com/ | host=[normal.com@] | invalid | invalid | | | | http://normal.com[user@vulndetector].com/ | host=[noirmal.com@vulndetector | | | host=normal.com | invalid | | http://normal.com[@]vulndetector.com/ | host=normal.com[@] | | |…
Recommended action: Upgrade to 12.1.5 or 12.0.31 by release line; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, HttpURI, for URI/URL parsing. The HttpURI class does insufficient validation on the authority segment of a URI. However the behaviour of HttpURI differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically HttpURI and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. Details Affected components The vulnerable component is the HttpURI class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. Attack overview The HttpURI class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user…
Recommended action: Upgrade to 12.0.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Jetty accepts the '+' character proceeding the content-length value in a HTTP/1 header field. This is more permissive than allowed by the RFC and other servers routinely reject such requests with 400 responses. There is no known exploit scenario, but it is conceivable that request smuggling could result if jetty is used in combination with a server that does not close the connection after sending such a 400 response. Workarounds There is no workaround as there is no known exploit scenario. Original Report RFC 9110 Secion 8.6 defined the value of Content-Length header should be a string of 0-9 digits. However we found that Jetty accepts "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. Payload: When sending this payload to Jetty, it can successfully parse and identify the length. When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. This behavior can lead to HTTP request smuggling and…
Recommended action: Upgrade to 12.0.1, 11.0.16, 10.0.16 or 9.4.52 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
URI use within Jetty's HttpURI class can parse invalid URIs such as http://localhost;/path as having an authority with a host of localhost;. A URIs of the type http://localhost;/path should be interpreted to be either invalid or as localhost; to be the userinfo and no host. However, HttpURI.host returns localhost; which is definitely wrong. Impact This can lead to errors with Jetty's HttpClient, and Jetty's ProxyServlet / AsyncProxyServlet / AsyncMiddleManServlet wrongly interpreting an authority with no host as one with a host. Patches Patched in PR #8146 for Jetty version 9.4.47. Patched in PR #8014 for Jetty versions 10.0.10, and 11.0.10 Workarounds None. For more information If you have any questions or comments about this advisory: Email us at security@webtide.com.
Recommended action: Upgrade to 11.0.10, 10.0.10 or 9.4.47 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.