Eclipse Jetty CVE-2026-8384

Exploitation requires two concurrent conditions: first, the target web application must be hosted on Eclipse Jetty (any version per current CPE data); second, and critically, the application's own authorization or routing logic must use the path string supplied by Jetty (e.g., via HttpServletRequest.getPathInfo() or getServletPath()) without independently normalizing or canonicalizing it prior to making access control decisions. Jetty's built-in alias checker protects Jetty's own static file serving - exploitation is limited entirely to application-layer code that trusts Jetty's unresolved path. Applications that normalize incoming paths, use framework-level security filters that canonicalize URIs, or restrict sensitive resources through network-layer controls are not exploitable. The CVSS PR:N metric confirms no authentication is required to send the crafted URI, but the attack produces no impact unless the vulnerable application-side path-trust pattern is present.

The NVD-assigned CVSS 3.1 score of 5.3 (Medium) with vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N reflects a network-reachable, low-complexity, unauthenticated attack with limited integrity impact. No EPSS score was provided in the intelligence data, and the vulnerability does not appear in CISA KEV, indicating no confirmed active exploitation at time of analysis. The zero confidentiality impact in the vector is notable - Jetty's alias checker prevents direct file disclosure; only the downstream web application's own authorization logic is at risk. This makes exploitability highly context-dependent: applications that independently resolve or validate received paths are unaffected, while those that naively trust Jetty's reported path for access decisions are vulnerable. Real-world risk is therefore lower than the CVSS score might suggest for well-designed applications, but significantly higher for legacy or poorly architected deployments where Jetty is trusted as the authoritative path resolver. The wildcard CPE (*:*) suggests all Jetty versions are considered affected, amplifying scope, but the absence of a POC and KEV listing tempers urgency.

An attacker sends an HTTP GET request to a Jetty-hosted application with a crafted URI such as GET /public;/../admin/secret.txt HTTP/1.1. Jetty's alias checker prevents it from serving the file directly, but the application's authorization middleware receives the unresolved path /public/../admin/secret.txt, evaluates it against the /public/ access rule (matching the leading segment), and incorrectly grants access - responding with the contents of admin/secret.txt. No public proof-of-concept has been identified at time of analysis, but the technique is straightforward to reproduce manually.