CVE-2024-6763

What it actually does

Eclipse Jetty's HttpURI parser does not fully validate the authority portion of a URI before extracting components such as scheme, userinfo, host, and port. For malformed or non-RFC-compliant URIs, Jetty may determine a different host than a common browser or another downstream HTTP client would use. Applications that rely on Jetty's parsed host value for allowlist, same-origin, redirect, proxy, callback, or fetch validation can therefore make an incorrect trust decision. Depending on how the application uses the URI after validation, this can result in open redirect, server-side request forgery, or policy bypass. The vulnerability is application-dependent: Jetty parsing alone is not enough; exploitable impact requires application logic that validates a URI with HttpURI and then redirects, fetches, proxies, or otherwise acts on the original or differently interpreted URI.

Why it matters to the business

The primary business risk is that web applications using affected Jetty URI parsing may be tricked into sending users or server-side requests to destinations that were intended to be blocked. In user-facing flows this can enable phishing or token theft through trusted-domain redirects; in server-side flows it can allow access attempts to internal services, metadata endpoints, or restricted administrative interfaces. The CVSS score is low and EPSS is currently low, with no CISA KEV listing and no reported exploit maturity in the provided data, so this is not typically an emergency mass-exploitation issue; however, the issue has been public for a long period and should be corrected during normal dependency remediation, especially in applications that implement URL allowlists, webhook fetchers, reverse proxies, redirect handlers, OAuth/SAML return URLs, or URL-preview functionality.

How an attack unfolds

An attacker first identifies an application endpoint that accepts a URL or URI from the user, such as a redirect target, callback URL, image fetcher, webhook destination, proxy URL, or import URL. The attacker then crafts a malformed URI whose authority segment is interpreted one way by Jetty's HttpURI validation code and another way by the browser or the HTTP client that ultimately follows or uses the URI. If the application checks the host extracted by Jetty and decides it is allowed, but later redirects the browser or initiates a server-side connection using a different interpretation of the same string, the request can be sent to an attacker-controlled or otherwise restricted host. In an open redirect scenario, the attacker sends a victim a trusted application URL that appears to pass validation but ultimately navigates the victim to an attacker-controlled site. In an SSRF scenario, the attacker submits a crafted URL that passes host allowlist checks but causes the server to connect to an internal or unintended destination. Successful exploitation depends heavily on application behavior and the URI sink, not merely on the presence of Jetty.

How to fix it

Upgrade affected Jetty-derived or downstream dependencies to fixed versions. For the provided affected package data, update io.jenkins.plugin-management:plugin-management-parent-pom to version 2.2.0 or later, and update eclipse/jetty.project to a version containing commit df524e6b29271c2e09ba9aea83c18dc9db464a31 or a later official release that includes the fix. Because the exploitability depends on application URI handling, also review application code that validates user-supplied URLs before redirecting, proxying, fetching, or storing them. Normalize and validate URIs using a single strict parser, reject invalid RFC-compliant URI forms rather than attempting to repair them, and compare the exact normalized destination that will be used by the eventual browser or HTTP client. Prefer allowlists based on canonical hostnames and resolved IP ranges, block private/link-local/loopback ranges for server-side fetches unless explicitly required, disallow embedded credentials in URLs, reject ambiguous authority syntax, and avoid using user-controlled absolute URLs for redirects when relative paths or server-generated callback identifiers can be used instead.

How to confirm the fix worked

Confirm dependency remediation with software composition analysis, Maven dependency trees, build manifests, container image SBOMs, and runtime classpath inspection to ensure affected Jetty artifacts or downstream components have been upgraded. For Maven-based builds, verify that io.jenkins.plugin-management:plugin-management-parent-pom resolves to 2.2.0 or later where applicable. For Jetty source or vendored builds, verify the fixed Jetty commit or a release containing it is present. Functionally test any URL-validation endpoints by submitting malformed authority values and confirming they are rejected before redirecting or fetching. Validation should compare the host accepted by application validation with the host actually reached by the browser or backend HTTP client. For SSRF-sensitive features, run controlled tests against blocked destinations such as localhost, RFC1918 ranges, and cloud metadata addresses and confirm they are denied even when obfuscated with encoded or malformed authority syntax.

Typical attack path

1. Find an application endpoint that accepts a user-controlled URI or URL.
2. Determine whether the application uses Jetty HttpURI or Jetty-based request/URI parsing to validate the supplied destination.
3. Submit malformed authority values that contain ambiguous host delimiters, encoded separators, userinfo-like segments, backslashes, extra at-signs, or unusual port/host syntax.
4. Observe whether validation accepts the URI as belonging to an allowed host while the browser or backend HTTP client resolves a different destination.
5. Use the accepted malformed URI in a phishing redirect, OAuth/login flow abuse, webhook/proxy fetch, URL preview, or server-side request workflow.
6. For SSRF, attempt to reach internal IP ranges, localhost-only services, cloud metadata endpoints, or otherwise blocked hosts through the parser discrepancy.
7. For open redirect, deliver the crafted trusted-domain URL to users to increase credibility of phishing or credential-capture activity.

How to detect it

To determine whether this issue was already exploited, review application access logs, reverse proxy logs, WAF logs, and application-specific audit logs for endpoints that accept URL-like parameters such as url, uri, redirect, redirect_uri, return, returnUrl, next, target, callback, webhook, image, fetch, proxy, and import. Look for malformed authority syntax, including backslashes in URLs, encoded slashes or backslashes near the hostname, multiple at-signs, embedded credentials, unusual port notation, localhost/private IP targets, and cloud metadata addresses. For open redirect investigation, correlate suspicious requests with 3xx responses and Location headers that point to unexpected external domains. For SSRF investigation, correlate inbound requests containing suspicious URL parameters with outbound connections from the application server to internal IP ranges, loopback addresses, link-local addresses, metadata endpoints, or attacker-controlled infrastructure. Useful log sources include web server access logs, Jetty request logs, application logs that record validation failures or outbound fetch destinations, reverse proxy logs, WAF events, DNS resolver logs, egress firewall/proxy logs, cloud VPC flow logs, and EDR telemetry for server-side HTTP client processes. There are no universal file-system or process artifacts for this vulnerability; indicators are primarily malformed request strings and unexpected outbound network activity.

• \\@
• %5c@
• %5C@
• %2f%2f
• %2F%2F
• @.*@
• http://127.0.0.1
• https://127.0.0.1
• http://localhost
• https://localhost
• http://0.0.0.0
• http://[::1]
• http://169.254.169.254
• http://metadata.google.internal
• http://169.254.170.2
• redirect_uri=
• returnUrl=
• return_url=
• callback=
• webhook=
• target=
• url=
• uri=
• Location: http://
• Location: https://

What your security team should do

• Inventory applications and services that embed Jetty or Jetty-derived URI parsing, including transitive dependencies and vendored copies.
• Prioritize remediation for internet-facing applications that accept user-supplied URLs and perform redirects, callbacks, webhooks, URL previews, imports, reverse proxying, or server-side fetching.
• Upgrade affected dependencies to fixed versions, including io.jenkins.plugin-management:plugin-management-parent-pom 2.2.0 or later where present, and Jetty versions containing the fixed upstream commit.
• Ask engineering teams to review URL validation code for parser mismatch risks, especially where one parser is used for validation and a different client or browser later consumes the original URL.
• Add negative tests for malformed URI authority handling to application security test suites.
• For SSRF-relevant functionality, enforce outbound egress controls at the network layer in addition to application-level URL validation.
• Monitor access logs and application logs for rejected or unusual URL parameters containing encoded delimiters, backslashes, multiple at-signs, embedded credentials, localhost, private IP ranges, or cloud metadata addresses.
• Treat exploitation evidence as application-specific; investigate suspicious redirect spikes, unusual outbound HTTP requests, and user reports of trusted links leading to unexpected domains.