Eclipse Jetty EUVD-2026-101944

Exploitation requires the target Jetty deployment to be configured with TryPathsHandler or TryFilesFilter using a rewrite/forward template that embeds the request path into a URI query string (e.g. 'index?p=$path'). This is a non-default, operator-chosen configuration - Jetty is not vulnerable out of the box, which is the primary limiting factor. When that configuration is present, exploitation is remote and unauthenticated (PR:N/UI:N): the attacker simply includes URI-reserved query characters ('&', '=') in the in-context request path. Realized impact is further bounded by how the backend application interprets the smuggled extra parameters, so the practical severity varies by downstream application.

This is a medium-severity query-parameter injection flaw (CVSS 4.0 base 6.9, vector AV:N/AC:L/AT:N/PR:N/UI:N) in Eclipse Jetty's TryPathsHandler/TryFilesFilter. The vendor-supplied CVSS indicates network-reachable, low-complexity, unauthenticated exploitation with no user interaction, but impact is constrained to integrity (VI:L) with no confidentiality or availability impact (VC:N/VA:N) - meaning this is parameter smuggling, not direct code execution or data theft. No EPSS score, CISA KEV listing, or public POC is present in the provided data, so there is no public exploit identified at time of analysis; the real-world priority is therefore moderate rather than urgent. A key signal conflict exists: the input tag labels this 'Information Disclosure,' yet the CVSS vector sets confidentiality to VC:N and only integrity to VI:L, so any disclosure would be an indirect, backend-dependent consequence of injected parameters rather than a confirmed primary impact - verify actual impact against the backend application behavior. Critically, exploitation depends entirely on a non-default configuration (the TryPathsHandler or TryFilesFilter being set up with a query-bearing rewrite template), which the CVSS AV:N/AC:L scoring does not reflect as a limiting precondition.

An attacker sends an HTTP request whose in-context path contains URI-reserved characters such as '&' or '=' (for example a path like '/s&a=1') to a Jetty instance configured to forward requests through TryPathsHandler or TryFilesFilter using a template such as 'index?p=$path'. Because the path is substituted directly into the query string, the server parses the attacker's injected '&a=1' as a separate, additional query parameter, allowing the attacker to smuggle parameters into the forwarded/rewritten request and influence downstream application logic. No public exploit code is identified at time of analysis, but the technique is simple and requires no authentication once the vulnerable rewrite template is in use.