-
CVSS Score
-Basic Information
CVE ID
-
GHSA ID
-
EPSS Score
-
CWE
-
Published
-
Updated
-
KEV Status
-
Technology
-
Technical Details
Vulnerability Intelligence
Miggo AI
Miggo AIMiggo AI| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| org.eclipse.jetty.http2:http2-common | maven | >= 9.3.0, <= 9.4.57 | 9.4.58 |
| org.eclipse.jetty.http2:http2-common | maven | >= 10.0.0, <= 10.0.25 | 10.0.26 |
| org.eclipse.jetty.http2:http2-common | maven | >= 11.0.0, <= 11.0.25 | 11.0.26 |
| org.eclipse.jetty.http2:jetty-http2-common | maven | >= 12.0.0, <= 12.0.24 | 12.0.25 |
| org.eclipse.jetty.http2:jetty-http2-common | maven | >= 12.1.0.alpha0, <= 12.1.0.beta2 | 12.1.0.beta3 |
JavaJavaMiggo AIRoot Cause AnalysisThe vulnerability lies in the HTTP/2 implementation's handling of certain control frames, which allows a client to trigger an unbounded number of stream resets from the server, leading to a denial of service. The analysis of the patch clearly shows two primary vulnerable code paths that were fixed. The first is in WindowUpdateBodyParser.onWindowUpdate, which improperly handled WINDOW_UPDATE frames with a zero-delta value. The second is in HTTP2Session.onWindowUpdate, which did not properly handle WINDOW_UPDATE frames sent to streams that were already closed. Both of these functions would be on the execution path during an exploit, as they are responsible for processing the malicious frames. The patch mitigates the vulnerability by introducing rate-limiting in these functions, preventing the server from being overwhelmed by reset-triggering frames. Therefore, these two functions are identified as the core vulnerable functions.
Thus, the attacker can exploit this vulnerability to cause the server to handle an unbounded number of concurrent streams from a client on the same connection. The exploitation is very simple: the client issues a request in a stream, and then sends the control frame that causes the server to send a RST_STREAM.
For example, a possible attack scenario can be:
The attacker can repeat steps 2+3 as rapidly as it is capable, since the active streams counter never exceeds 1 and the attacker does not need to wait for the response from the server. This leads to resource exhaustion and distributed denial of service vulnerabilities with an impact of: CPU overload and/or memory exhaustion (implementation dependant)
The vulnerability takes advantage of a design flow in the HTTP/2 protocol that was also used in the Rapid Reset vulnerability (CVE-2023-44487) which was exploited as a zero-day in the wild in August 2023 to October 2023, against multiple services and vendors. The Rapid Reset vulnerability uses RST_STREAM frames sent from the client, in order to create an unbounded amount of concurrent streams - it was given a CVSS score of 7.5. Rapid Reset was mostly mitigated by limiting the number/rate of RST_STREAM sent from the client, which does not mitigate the MadeYouReset attack - since it triggers the server to send a RST_STREAM.
A quick and easy mitigation will be to limit the number/rate of RST_STREAMs sent from the server. It is also possible to limit the number/rate of control frames sent by the client (e.g. WINDOW_UPDATE and PRIORITY), and treat protocol flow errors as a connection error.
As mentioned in our previous message, this is a protocol-level vulnerability that affects multiple vendors and implementations. Given its broad impact, it is the shared responsibility of all parties involved to handle the disclosure process carefully and coordinate mitigations effectively.
If you have any questions, we will be happy to clarify or schedule a Zoom call.
Gal, Anat and Yaniv.
A denial of service vulnerability similar to Rapid Reset, but where the client triggers a reset from the server by sending a malformed or invalid frame.
In particular, this may be triggered by WINDOW_UPDATE frames that are invalid (e.g. with delta==0 or when the delta makes the window exceed 2^31-1).
Patch has been merged into 12.0.x mainline via https://github.com/jetty/jetty.project/pull/13449.
No workarounds apart disabling HTTP/2.
Ongoing coverage of React2Shell