Eclipse Jetty
Monthly
Security-constraint bypass in Eclipse Jetty leaves some request URL patterns unprotected when annotation and deployment-descriptor security metadata are mixed, specifically in the jetty-annotations and jetty-eeN-annotations modules. The flaw triggers only in a narrow application layout: a servlet declared in web.xml with more than one url-pattern, a web.xml security-constraint that covers only a subset of those patterns, and @ServletSecurity annotations present at the same time, in which case the Jakarta Servlet specification's authoritative url-pattern precedence rules are not applied and the uncovered patterns remain reachable. Because the resulting access is reachable over the network with no credentials (CVSS 4.0 AV:N/PR:N/UI:N, independently assessed as CVSS 3.1 AV:N/AC:L/PR:N/UI:N), an unauthenticated remote attacker can read content that should have been restricted, yielding a high confidentiality impact with a low integrity impact and no availability impact; exploitation is strictly gated by the application-level web.xml/annotation layout rather than by the Jetty version alone, and no public exploit identified at time of analysis.
Eclipse Jetty's HttpClient can disclose proxy authentication credentials to a malicious server when the server returns a 407 Proxy Authentication Required status. This information disclosure (CWE-200) affects applications using Jetty's HttpClient with an authenticated forward proxy and connecting to attacker-controlled destinations. Exploitation requires the attacker to control the destination server and the client to be configured with proxy credentials; no public exploit code has been identified at time of analysis, and the CVSS 4.0 score is 8.2 (High).
Path-normalization weakness in Eclipse Jetty's HttpClient causes credential disclosure: when HttpClient receives a redirect whose target contains a non-normalized traversal segment such as /secure/../evil, Jetty matches the stored Authorization credential against the literal /secure prefix rather than resolving the path to /evil, and then follows the redirect - sending the /secure-scoped Authorization header to an endpoint that should never receive it. Per the provided CVSS vector (PR:N) the attacker is unauthenticated, but exploitation carries high attack complexity (AC:H): the attacker must be able to control or influence the redirect response returned to HttpClient, and must already have a malicious application deployed on the SAME domain as the target so the leaked header lands on an endpoint they control. No public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis.
HTTP/2 thread-exhaustion denial-of-service in Eclipse Jetty allows unauthenticated remote clients to permanently block all server threads by exploiting a race condition in RST_STREAM and GOAWAY frame handling. The race incorrectly resets the `HTTP2Flusher.terminated` field from a non-null terminal state back to null, allowing new write-queue entries to be enqueued in a flusher that will never drain them; the write-blocked threads waiting on those entries hang indefinitely. Across five affected Jetty major branches (9.4, 10.0, 11.0, 12.0, 12.1), any internet-exposed HTTP/2 endpoint is reachable without authentication. No public exploit has been identified at time of analysis.
HTTP/1.1 request smuggling in Eclipse Jetty allows unauthenticated remote attackers to desynchronize request boundary parsing between Jetty and an upstream proxy, enabling manipulation of other users' HTTP sessions. The root cause is Jetty's acceptance of a bare LF character (\n) as a line terminator during chunked transfer encoding parsing - specifically in chunk extensions, chunk data termination, or trailer termination - where RFC 7230 mandates CRLF (\r\n). Depending on the Jetty version and configured HTTP compliance mode, a crafted request can cause the proxy and Jetty to disagree on where one request ends and the next begins, enabling request injection against co-located tenants. No public exploit has been identified at time of analysis.
Unauthenticated remote denial-of-service in Eclipse Jetty's WebSocket implementation allows any network-accessible client to exhaust the JVM heap by sending a single WebSocket frame with an unknown opcode and an arbitrarily large declared payload length. When auto-fragmentation is enabled, unknown opcodes bypass the normal maximum frame size check, causing Jetty to attempt heap allocation for the declared payload size before the opcode is ever validated - a logic-ordering flaw classified under CWE-770. The CVSS 4.0 score of 8.7 (AV:N/AC:L/PR:N/UI:N/VA:H) reflects high impact and low attack barrier; no public exploit has been identified at time of analysis.
HTTP request smuggling in Eclipse Jetty's HTTP/1.1 parser lets remote unauthenticated attackers desynchronize front-end/back-end request boundaries by abusing quoted-string chunk extensions. Jetty incorrectly terminates chunk-extension parsing at a CRLF located inside an unterminated quoted-string (e.g. `1;a="`) rather than rejecting it, so attacker-controlled bytes are reinterpreted as a second, smuggled request on the same TCP connection. Publicly available exploit code exists (a working Python PoC ships in the GHSA advisory), though EPSS is very low (0.03%, 9th percentile) and the issue is not on CISA KEV.
Privilege escalation in Eclipse Jetty 9.4.0-12.1.7 allows unauthenticated remote attackers to bypass authentication via ThreadLocal variable pollution in JASPIAuthenticator. Early returns from authentication checks fail to clear ThreadLocal values, causing subsequent requests on the same thread to inherit elevated privileges. CVSS 7.4 with high complexity but no authentication required. EPSS and KEV status not provided; no public exploit identified at time of analysis. Affects all major Jetty versions from 9.x through 12.x.
Query-parameter injection in Eclipse Jetty's TryPathsHandler and TryFilesFilter allows unauthenticated remote attackers to inject extra query parameters when a deployment uses a non-default configuration that forwards the request path into a template query string such as index?p=$path. Exposure is limited to sites using that operator-chosen pattern; the assessed CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N) and CVSS 4.0 base score of 6.9 describe a medium-severity, configuration-dependent flaw whose realized impact depends on how the backend interprets the smuggled parameters. No public exploit code or confirmed active exploitation was identified at time of analysis.
Eclipse Jetty mishandles HTTP URI path parameters containing semicolons combined with traversal sequences, delivering an unresolved path (e.g., `/public/../admin/secret.txt`) to downstream web applications instead of the canonicalized form (e.g., `/admin/secret.txt`). Web applications that delegate path-based authorization decisions to Jetty-provided paths are susceptible to confusion attacks where an attacker crafts a URI like `/public;/../admin/secret.txt` to receive a path that bypasses application-layer access controls. Jetty itself is shielded by its alias checker and will not serve restricted files directly; the integrity risk materializes only in applications that consume the unresolved path for routing or authorization logic. No public exploit code or CISA KEV listing is present at time of analysis.
Eclipse Jetty fails to enforce RFC 9110/9112's requirement that the HTTP request authority (host and port) match the value in the Host header across all supported protocol versions - HTTP/1, HTTP/2, and HTTP/3. Unauthenticated network attackers can exploit this input validation gap to manipulate Host-header-derived URI constructions (particularly redirect targets on login pages), influence virtual host selection, corrupt reverse proxy routing decisions, and produce misleading access logs. No public exploit has been identified at time of analysis and the vulnerability is not in CISA KEV, but the attack surface is meaningful in any Jetty deployment that performs host-based routing or generates redirects from the Host header.
HTTP/1.1 trailer leakage in Eclipse Jetty allows a remote unauthenticated attacker to read trailer headers from a previous request when sharing a persistent connection with another party. Trailers sent in an initial request are incorrectly retained in the server's connection state, causing them to bleed into all subsequent requests on the same keep-alive connection - either appended wholesale (if the later request has no trailers) or merged with the later request's own trailers. No public exploit has been identified at time of analysis, and the vulnerability is not listed in CISA KEV.
Security-constraint bypass in Eclipse Jetty leaves some request URL patterns unprotected when annotation and deployment-descriptor security metadata are mixed, specifically in the jetty-annotations and jetty-eeN-annotations modules. The flaw triggers only in a narrow application layout: a servlet declared in web.xml with more than one url-pattern, a web.xml security-constraint that covers only a subset of those patterns, and @ServletSecurity annotations present at the same time, in which case the Jakarta Servlet specification's authoritative url-pattern precedence rules are not applied and the uncovered patterns remain reachable. Because the resulting access is reachable over the network with no credentials (CVSS 4.0 AV:N/PR:N/UI:N, independently assessed as CVSS 3.1 AV:N/AC:L/PR:N/UI:N), an unauthenticated remote attacker can read content that should have been restricted, yielding a high confidentiality impact with a low integrity impact and no availability impact; exploitation is strictly gated by the application-level web.xml/annotation layout rather than by the Jetty version alone, and no public exploit identified at time of analysis.
Eclipse Jetty's HttpClient can disclose proxy authentication credentials to a malicious server when the server returns a 407 Proxy Authentication Required status. This information disclosure (CWE-200) affects applications using Jetty's HttpClient with an authenticated forward proxy and connecting to attacker-controlled destinations. Exploitation requires the attacker to control the destination server and the client to be configured with proxy credentials; no public exploit code has been identified at time of analysis, and the CVSS 4.0 score is 8.2 (High).
Path-normalization weakness in Eclipse Jetty's HttpClient causes credential disclosure: when HttpClient receives a redirect whose target contains a non-normalized traversal segment such as /secure/../evil, Jetty matches the stored Authorization credential against the literal /secure prefix rather than resolving the path to /evil, and then follows the redirect - sending the /secure-scoped Authorization header to an endpoint that should never receive it. Per the provided CVSS vector (PR:N) the attacker is unauthenticated, but exploitation carries high attack complexity (AC:H): the attacker must be able to control or influence the redirect response returned to HttpClient, and must already have a malicious application deployed on the SAME domain as the target so the leaked header lands on an endpoint they control. No public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis.
HTTP/2 thread-exhaustion denial-of-service in Eclipse Jetty allows unauthenticated remote clients to permanently block all server threads by exploiting a race condition in RST_STREAM and GOAWAY frame handling. The race incorrectly resets the `HTTP2Flusher.terminated` field from a non-null terminal state back to null, allowing new write-queue entries to be enqueued in a flusher that will never drain them; the write-blocked threads waiting on those entries hang indefinitely. Across five affected Jetty major branches (9.4, 10.0, 11.0, 12.0, 12.1), any internet-exposed HTTP/2 endpoint is reachable without authentication. No public exploit has been identified at time of analysis.
HTTP/1.1 request smuggling in Eclipse Jetty allows unauthenticated remote attackers to desynchronize request boundary parsing between Jetty and an upstream proxy, enabling manipulation of other users' HTTP sessions. The root cause is Jetty's acceptance of a bare LF character (\n) as a line terminator during chunked transfer encoding parsing - specifically in chunk extensions, chunk data termination, or trailer termination - where RFC 7230 mandates CRLF (\r\n). Depending on the Jetty version and configured HTTP compliance mode, a crafted request can cause the proxy and Jetty to disagree on where one request ends and the next begins, enabling request injection against co-located tenants. No public exploit has been identified at time of analysis.
Unauthenticated remote denial-of-service in Eclipse Jetty's WebSocket implementation allows any network-accessible client to exhaust the JVM heap by sending a single WebSocket frame with an unknown opcode and an arbitrarily large declared payload length. When auto-fragmentation is enabled, unknown opcodes bypass the normal maximum frame size check, causing Jetty to attempt heap allocation for the declared payload size before the opcode is ever validated - a logic-ordering flaw classified under CWE-770. The CVSS 4.0 score of 8.7 (AV:N/AC:L/PR:N/UI:N/VA:H) reflects high impact and low attack barrier; no public exploit has been identified at time of analysis.
HTTP request smuggling in Eclipse Jetty's HTTP/1.1 parser lets remote unauthenticated attackers desynchronize front-end/back-end request boundaries by abusing quoted-string chunk extensions. Jetty incorrectly terminates chunk-extension parsing at a CRLF located inside an unterminated quoted-string (e.g. `1;a="`) rather than rejecting it, so attacker-controlled bytes are reinterpreted as a second, smuggled request on the same TCP connection. Publicly available exploit code exists (a working Python PoC ships in the GHSA advisory), though EPSS is very low (0.03%, 9th percentile) and the issue is not on CISA KEV.
Privilege escalation in Eclipse Jetty 9.4.0-12.1.7 allows unauthenticated remote attackers to bypass authentication via ThreadLocal variable pollution in JASPIAuthenticator. Early returns from authentication checks fail to clear ThreadLocal values, causing subsequent requests on the same thread to inherit elevated privileges. CVSS 7.4 with high complexity but no authentication required. EPSS and KEV status not provided; no public exploit identified at time of analysis. Affects all major Jetty versions from 9.x through 12.x.
Query-parameter injection in Eclipse Jetty's TryPathsHandler and TryFilesFilter allows unauthenticated remote attackers to inject extra query parameters when a deployment uses a non-default configuration that forwards the request path into a template query string such as index?p=$path. Exposure is limited to sites using that operator-chosen pattern; the assessed CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N) and CVSS 4.0 base score of 6.9 describe a medium-severity, configuration-dependent flaw whose realized impact depends on how the backend interprets the smuggled parameters. No public exploit code or confirmed active exploitation was identified at time of analysis.
Eclipse Jetty mishandles HTTP URI path parameters containing semicolons combined with traversal sequences, delivering an unresolved path (e.g., `/public/../admin/secret.txt`) to downstream web applications instead of the canonicalized form (e.g., `/admin/secret.txt`). Web applications that delegate path-based authorization decisions to Jetty-provided paths are susceptible to confusion attacks where an attacker crafts a URI like `/public;/../admin/secret.txt` to receive a path that bypasses application-layer access controls. Jetty itself is shielded by its alias checker and will not serve restricted files directly; the integrity risk materializes only in applications that consume the unresolved path for routing or authorization logic. No public exploit code or CISA KEV listing is present at time of analysis.
Eclipse Jetty fails to enforce RFC 9110/9112's requirement that the HTTP request authority (host and port) match the value in the Host header across all supported protocol versions - HTTP/1, HTTP/2, and HTTP/3. Unauthenticated network attackers can exploit this input validation gap to manipulate Host-header-derived URI constructions (particularly redirect targets on login pages), influence virtual host selection, corrupt reverse proxy routing decisions, and produce misleading access logs. No public exploit has been identified at time of analysis and the vulnerability is not in CISA KEV, but the attack surface is meaningful in any Jetty deployment that performs host-based routing or generates redirects from the Host header.
HTTP/1.1 trailer leakage in Eclipse Jetty allows a remote unauthenticated attacker to read trailer headers from a previous request when sharing a persistent connection with another party. Trailers sent in an initial request are incorrectly retained in the server's connection state, causing them to bleed into all subsequent requests on the same keep-alive connection - either appended wholesale (if the later request has no trailers) or merged with the later request's own trailers. No public exploit has been identified at time of analysis, and the vulnerability is not listed in CISA KEV.