CVE-2025-11143

What it actually does

The flaw is caused by inconsistent handling of invalid, unusual, or ambiguous URIs by Eclipse Jetty compared with other URI parsers that may sit in front of or behind it, such as reverse proxies, web application firewalls, API gateways, authentication middleware, routing layers, or application frameworks. If one component normalizes or interprets a request path differently than Jetty or the application using Jetty, security controls that rely on path, route, extension, or blacklist matching may make an incorrect decision. The most likely impact is limited integrity impact through access-control, routing, filter, or blacklist bypass in configurations where multiple components parse the same malformed URI differently. In lower-impact cases, responses or error behavior may reveal implementation details about the server-side parsing stack.

Why it matters to the business

Organizations using Eclipse Jetty may have application security controls that appear to block sensitive routes or disallowed URL patterns but can be bypassed with specially crafted malformed URLs in certain deployments. The CVSS score and EPSS probability are low, there is no CISA KEV listing, and no public exploit maturity is reported, so this is not currently a broad emergency; however, internet-facing applications, APIs, management consoles, and services relying on URL-based allowlists, denylists, authentication exclusions, or proxy-layer enforcement should treat it as a configuration-sensitive risk because a successful bypass can expose restricted functionality or allow unintended requests to reach backend handlers.

How an attack unfolds

An attacker first identifies a Jetty-backed application, often by observing headers, error pages, behavior, or framework fingerprints. They then map which paths are protected or filtered by an upstream component, such as a proxy, WAF, gateway, servlet filter, or custom middleware. The attacker submits deliberately unusual request targets containing ambiguous encodings, malformed percent-encoding, path parameters, dot segments, encoded separators, repeated slashes, backslashes, or other parser edge cases. If the upstream control interprets the URI one way and Jetty or the application interprets it another way, the upstream layer may allow the request while the backend routes it to a restricted resource or handler. Exploitation is highly deployment-dependent and generally requires trial and error because the attacker must find a parser mismatch that aligns with the target application’s routing and security rules.

How to fix it

Upgrade Eclipse Jetty to a vendor-fixed release when available for the affected major/minor line and track Eclipse Jetty security advisories for the exact patched versions, since no fixed versions were provided in the input. Where immediate upgrade is not possible, reduce exposure by enforcing URI normalization and rejection at a single trusted ingress point before requests reach Jetty. Configure reverse proxies, gateways, WAFs, and applications to reject malformed request targets, invalid percent-encoding, encoded path separators where not required, backslashes in paths, path traversal sequences, duplicate or ambiguous slashes, and semicolon path parameters if the application does not need them. Avoid security decisions based only on blacklist matching of raw URLs; prefer positive route allowlists, centralized authentication/authorization in the application, and canonicalized path comparison. Ensure upstream components and Jetty use consistent URI normalization behavior, and add regression tests for protected routes using ambiguous URI variants.

How to confirm the fix worked

Confirm exposure by inventorying services that embed or depend on Eclipse Jetty and identifying any use of proxy, gateway, WAF, servlet filter, or application logic that makes access-control decisions from request paths. Verify the deployed Jetty version against Eclipse’s patched advisory once available. In a non-production test environment, send ambiguous URI variants to protected routes and confirm they are consistently rejected by every layer. Test encoded slashes, encoded dot segments, backslashes, semicolon path parameters, duplicate slashes, absolute-form request targets, and malformed percent-encoding. A successful fix or mitigation should produce uniform 400, 403, or equivalent denial responses before the request reaches protected backend handlers, with no difference between raw and normalized path handling.

Typical attack path

1. Identify an application or API endpoint likely served by Eclipse Jetty or a Jetty-based framework.
2. Determine which routes, file paths, extensions, or API operations are blocked, authenticated, or filtered by upstream controls.
3. Send baseline requests to compare proxy, gateway, WAF, Jetty, and application response behavior.
4. Craft malformed or ambiguous URIs using encoded separators, dot segments, backslashes, semicolon path parameters, duplicate slashes, double encoding, or invalid percent-encoding.
5. Observe status codes, redirects, error pages, response bodies, timing, or backend-specific errors that indicate different components parsed the URI differently.
6. Refine the request until an upstream security decision allows the request while Jetty or the application routes it to a sensitive handler.
7. Use the bypass to access restricted functionality, evade URL blacklist rules, or disclose implementation details.

How to detect it

There are no known public exploit indicators or named threat actors associated with this issue from the provided data, so detection should focus on evidence of URI parser probing and successful access to protected resources through malformed request targets. Review reverse proxy, load balancer, WAF, API gateway, Jetty request logs, application access logs, and authentication/authorization logs. Look for requests containing encoded path separators, double-encoded characters, dot-segment traversal, semicolon path parameters, backslashes, invalid percent-encoding, duplicate slashes, or absolute-form URLs, especially when followed by 200, 204, 302, or other successful responses for endpoints that normally require authentication or are blocked. Correlate upstream logs with Jetty/application logs to identify mismatched paths, status codes, or route names for the same request. Investigate sequences where a single source repeatedly varies URL encoding against administrative, API, static file, upload, download, or protected application paths. Also review WAF allow/block decisions where the WAF logged a benign path but the backend application logged a different normalized route.

• %2f
• %2F
• %5c
• %5C
• %2e
• %2E
• %252f
• %252F
• %255c
• %255C
• %252e
• %252E
• ..%2f
• ..%2F
• %2e%2e
• %2E%2E
• %2e%2e%2f
• %2E%2E%2F
• %2e%2e/
• ..;
• ;/
• %3b
• %3B
• //
• \\
• %00
• %u002f
• %u005c
• %c0%af
• %c1%9c
• GET http://
• POST http://
• Invalid URI
• BadMessageException
• Illegal character in path
• Ambiguous URI
• ambiguous path
• Bad Request: invalid URI

What your security team should do

• Inventory all internet-facing and internal applications using Eclipse Jetty, including embedded Jetty in Java services and third-party products.
• Monitor Eclipse Jetty advisories and update to the patched version for the deployed branch as soon as the vendor publishes or confirms fixed releases.
• Prioritize review for services where URL path matching controls authentication, authorization, routing, file access, API allowlists, denylists, or WAF exceptions.
• Add ingress-layer rules to reject malformed or ambiguous URIs that the application does not explicitly require.
• Review proxy, gateway, WAF, and application normalization behavior to ensure security decisions are made on a canonical URI representation.
• Create regression tests for sensitive endpoints using encoded separators, double encoding, dot segments, path parameters, backslashes, and duplicate slashes.
• Search historical access logs for URI normalization probes and unexplained successful responses to malformed requests against protected paths.
• Because EPSS is very low and there is no KEV listing or known public exploit maturity, schedule remediation based on exposure and reliance on URL-based controls rather than treating it as an active mass-exploitation event.