Visit Jetty Home Page

CVE-2024-6763 Guidance

Information on the status of CVE-2024-6763 in NES for Jetty

Summary

CVE-2024-6763 describes insufficient validation of the authority component of a URI by Jetty's HttpURI class. For some malformed inputs, the host that HttpURI extracts differs from the host a browser would resolve. An application that passes attacker-controlled input to HttpURI and then uses the extracted host to make an allow-list or block-list decision can therefore be redirected to an unintended origin.

The upstream advisory records a fix in Jetty 12.0.12, and lists every earlier release as affected. NES for Jetty 9.4, 10.0 and 11.0 have narrowed the behaviour substantially but cannot fully resolve this CVE, for the reason set out below. Scanners will continue to report CVE-2024-6763 against org.eclipse.jetty:jetty-http on all three branches, and the HeroDevs VEX feed records these branches as affected rather than fixed.

If your application does not reference org.eclipse.jetty.http.HttpURI in its own code, you are not exposed. See Determining whether you are affected.

Why this cannot be fully fixed on Jetty 9.4, 10.0 and 11.0

The residual issue is the userinfo portion of the authority — the part before an @ in http://userinfo@host/.

Jetty 12 is based on RFC 9110, which requires that userinfo be rejected in an HTTP URI. The upstream fix relies on that rule. Jetty 9.4 is based on RFC 2616 and Jetty 10.0 and 11.0 are based on RFC 7230; both of those specifications permit userinfo. Backporting outright rejection would make these branches non-conformant with the HTTP specification they implement, and would break applications that legitimately supply credentials in a URI.

Upstream has stated that this part of the CVE cannot be addressed on the 9.4, 10.0 and 11.0 branches for this reason, and NES for Jetty follows that assessment. Removing the behaviour would be a breaking change of exactly the kind Never-Ending Support exists to avoid.

What NES for Jetty does address

Current NES releases on all three branches reject malformed authorities outright rather than parsing them into a misleading host:

  • Characters that are not permitted in an authority (for example \) raise IllegalArgumentException.
  • Malformed percent-encoding in the authority raises IllegalArgumentException.
  • Invalid IP literals are validated and rejected.
  • The scheme is validated.

On Jetty 10.0 and 11.0, the authority is additionally terminated correctly at # and ?, so inputs such as http://example.com#@attacker.example/ now resolve the same host a browser resolves.

The one remaining divergence is an authority containing a syntactically valid userinfo section, such as http://example.com&@attacker.example/, which resolves to attacker.example. This is the case that cannot be changed without breaking RFC conformance.

Determining whether you are affected

The vulnerable code path is HttpURI used directly as a URI validation utility by application code. Jetty's own server, client and proxy request handling does not use HttpURI in the vulnerable way, and the upstream advisory states that Jetty's usage of the class is not vulnerable.

Most applications consume jetty-http only as a transitive dependency of jetty-server and never reference HttpURI. To confirm this for your application, search your source and your built artifacts for references to the class:

grep -rn "org.eclipse.jetty.http.HttpURI" src/
javap -c -p -classpath your-application.jar \
  $(unzip -Z1 your-application.jar '*.class' | sed 's|/|.|g; s|\.class$||') \
  2>/dev/null | grep -c "org/eclipse/jetty/http/HttpURI"

If there are no references, the vulnerable code is not reachable from your application and you may record CVE-2024-6763 as not applicable for your product. See Recording this in your own VEX statement.

If your application does call HttpURI on untrusted input and uses the result for a security decision, do not rely on getHost() alone.

How HttpURI.from(untrustedInput) treats an authority that carries user info, e.g. http://good.example;@attacker.example/, differs by version:

  • NES for Jetty 10.0.27-10.0.31 and 11.0.27-11.0.31 throw IllegalArgumentException: Bad authority.
  • NES for Jetty 10.0.32 and 11.0.32 do not throw and do not flag the user info.
  • Jetty 12.0.12 and later do not throw, but record the user info as a compliance violation (uri.hasViolation(UriCompliance.Violation.USER_INFO) returns true).

Handle both a thrown exception and a recorded violation as a rejection:

import org.eclipse.jetty.http.HttpURI;
import org.eclipse.jetty.http.UriCompliance;

HttpURI uri;
try {
    uri = HttpURI.from(untrustedInput);
} catch (IllegalArgumentException ex) {
    throw new IllegalArgumentException("URI authority is not valid");
}

if (uri.hasViolation(UriCompliance.Violation.USER_INFO)) {
    throw new IllegalArgumentException("URI authority contains userinfo");
}

String host = uri.getHost();

On 10.0.32 and 11.0.32 neither signal is raised, so validate the host with a parser that enforces RFC 9110 rather than relying on HttpURI alone.

NES for Jetty 9.4 has no UriCompliance, and HttpURI does not throw and does not flag the user info for these authorities, so it leaves you nothing to check. Validate the host with an RFC 9110 parser rather than relying on HttpURI.

Applications that require the complete upstream fix must migrate to Jetty 12.0.12 or later.

Recording this in your own VEX statement

The HeroDevs VEX feed reports NES for Jetty jetty-http as affected, because HeroDevs cannot know whether a given consumer calls HttpURI directly.

If you have confirmed that your application does not reference HttpURI, you can publish your own VEX statement asserting not_affected for your product, with the justification vulnerable_code_not_in_execute_path, and cite this page and the verification you performed. That is a claim about your own code, which only you can make.

Additional Information

You can read more about this CVE in the CVE-2024-6763 vulnerability entry.

The upstream advisory is GHSA-qh8g-58pp-2wxh.