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
\) raiseIllegalArgumentException. - 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.
Recommended mitigation for direct users of HttpURI
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)returnstrue).
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.