CVE-2026-8384

What it actually does

This issue is a path-confusion/path-traversal weakness in Eclipse Jetty’s handling of HTTP URIs containing semicolon path parameters followed by parent-directory traversal sequences. A request such as `/public;/../admin/secret.txt` can be exposed to an application as an unresolved path like `/public/../admin/secret.txt` rather than the normalized `/admin/secret.txt`. Jetty’s own static resource serving is not directly vulnerable because its alias checker prevents serving unresolved resources, but applications or middleware that trust Jetty-provided resolved paths for authorization, routing, access-control, auditing, or file selection may make incorrect security decisions. The direct CVSS impact is limited to integrity because the main risk is bypassing application logic rather than Jetty independently disclosing files.

Why it matters to the business

Organizations running Jetty-backed applications may have application-specific authorization or routing bypass exposure if their code depends on Jetty-normalized paths to decide whether a user can access protected endpoints or resources. The practical business risk is unauthorized access to administrative functionality, policy bypass, incorrect request handling, or unintended modification of application state, depending on how the application uses the path. The CVSS score is moderate and EPSS is currently low, and this is not listed in CISA KEV or known ransomware use, but exploit code availability means internet-facing Jetty applications should still be reviewed and remediated promptly.

How an attack unfolds

An attacker sends a crafted HTTP request containing a semicolon path parameter before a traversal sequence, for example `/public;/../admin/secret.txt`. Jetty parses and forwards path information in a way that can leave the application with an unresolved path containing `..` segments. If the application assumes the path has already been safely normalized by Jetty, it may perform authorization checks against the wrong logical path, route the request incorrectly, or apply public-resource rules to a request that ultimately targets a restricted application path. Successful exploitation requires an application behavior that trusts the unresolved path; Jetty’s built-in static file serving protections alone are not enough for exploitation.

How to fix it

Upgrade Eclipse Jetty to a vendor-provided fixed release as soon as one is available for the deployed major/minor line. Because no fixed version was provided in the input, consult the Eclipse Jetty security advisory and package manager metadata for the exact patched version applicable to Jetty 9.x, 10.x, 11.x, or 12.x deployments. As a defense-in-depth measure, update application code so authorization and routing decisions are made only after strict canonicalization and normalization of paths, and reject requests containing ambiguous path constructs such as semicolon path parameters combined with `..` traversal. Avoid relying solely on container-provided path values for security decisions. If immediate upgrade is not possible, use a reverse proxy, WAF, or servlet filter to block or normalize suspicious URI patterns including `;/../`, `%3b/../`, `%3B/../`, `;%2f..`, and encoded traversal variants before they reach the application.

How to confirm the fix worked

Confirm the deployed Jetty version is upgraded to a release identified by Eclipse as fixed for this issue. Review application code for path-based access checks that use servlet request path fields or Jetty-provided path values without independent normalization. Test representative protected routes with crafted requests containing semicolon path parameters and traversal sequences, such as `/public;/../admin/secret.txt`, and verify they are rejected or handled identically to direct access to the protected path. Validate that reverse proxies, WAFs, and application filters block both plain and URL-encoded variants. Regression tests should assert that ambiguous paths containing `;` and `..` cannot alter authorization, routing, or file-selection outcomes.

Typical attack path

1. Identify a web application or API running on Eclipse Jetty.
2. Probe for semicolon path-parameter handling using requests that combine `;` and `../` path segments.
3. Compare responses between normal protected paths and crafted paths such as `/public;/../admin/...`.
4. Look for differences in status codes, redirects, response bodies, authentication prompts, or application behavior indicating path confusion.
5. Use the crafted URI pattern to reach restricted routes, bypass path-based authorization, or trigger unintended application logic.
6. If write-capable endpoints are exposed through the bypass, perform unauthorized state-changing actions.

How to detect it

Review web server, reverse proxy, load balancer, WAF, and application access logs for requests containing semicolon path parameters followed by traversal patterns, especially attempts that target administrative, configuration, upload, file, or API routes. Useful log sources include Jetty request logs, application framework logs, reverse proxy logs such as NGINX or Apache access logs, WAF event logs, and centralized HTTP telemetry. Look for requests containing `;/../`, encoded equivalents such as `%3b%2f..`, `%3B/..`, `%2e%2e`, or mixed-encoding traversal. Investigate cases where these requests returned non-error responses such as HTTP 200, 201, 204, 302, or application-specific success responses. Compare the requested crafted path with the normalized target path to determine whether a protected resource or route was reached. Also review authentication and authorization logs around the same timestamps for denied direct access followed by successful crafted-path access from the same IP, user agent, or session.

• ;/../
• %3b/../
• %3B/../
• ;%2f../
• ;%2F../
• ;/..%2f
• ;/..%2F
• %3b%2f..%2f
• %3B%2F..%2F
• /public;/../admin/secret.txt
• "GET /public;/../
• "POST /public;/../
• "PUT /public;/../
• "DELETE /public;/../

What your security team should do

• Inventory all internet-facing and internal applications using Eclipse Jetty, including embedded Jetty in third-party products and Java services.
• Prioritize applications that perform path-based authorization, serve user-accessible and administrative routes from the same host, or use custom servlet filters for routing/security decisions.
• Patch Jetty to the vendor-fixed version once available for the deployed branch, and track vendor advisories if exact fixed versions are not yet published in internal package sources.
• Add temporary WAF, reverse-proxy, or servlet-filter rules to reject requests containing semicolon path parameters combined with traversal sequences.
• Search recent HTTP access logs for `;/../`, URL-encoded semicolon/traversal variants, and unusual access attempts against administrative or restricted paths.
• Review application code to ensure security checks use canonicalized paths and do not trust unresolved request URI/path values.
• Add unit and integration tests for semicolon path-parameter traversal cases to prevent future regressions.