Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Technical Details Below is a technical explanation of a newly discovered vulnerability in HTTP/2, which we refer to as “MadeYouReset.” MadeYouReset Vulnerability Summary The MadeYouReset DDoS vulnerability is a logical vulnerability in the HTTP/2 protocol, that uses malformed HTTP/2 control frames in order to break the max concurrent streams limit - which results in resource exhaustion and distributed denial of service. Mechanism The vulnerability uses malformed HTTP/2 control frames, or malformed flow, in order to make the server reset streams created by the client (using the RSTSTREAM frame). The vulnerability could be triggered by several primitives, defined by the RFC of HTTP/2 (RFC 9113). The Primitives are: 1. WINDOWUPDATE frame with an increment of 0 or an increment that makes the window exceed 2^31 - 1. (section 6.9 + 6.9.1) 2. HEADERS or DATA frames sent on a half-closed (remote) stream (which was closed using the ENDSTREAM flag). (note that for some implementations it's…
Recommended action: Upgrade to 12.1.0.beta3 or 12.0.25 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Original Report In Eclipse Jetty versions 12.0.0 to 12.0.16 included, an HTTP/2 client can specify a very large value for the HTTP/2 settings parameter SETTINGSMAXHEADERLISTSIZE. The Jetty HTTP/2 server does not perform validation on this setting, and tries to allocate a ByteBuffer of the specified capacity to encode HTTP responses, likely resulting in OutOfMemoryError being thrown, or even the JVM process exiting. Impact Remote peers can cause the JVM to crash or continuously report OOM. Patches 12.0.17 Workarounds No workarounds. References https://github.com/jetty/jetty.project/issues/12690
Recommended action: Upgrade to 12.0.17 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact If an HTTP/2 connection gets TCP congested, when an idle timeout occurs the HTTP/2 session is marked as closed, and then a GOAWAY frame is queued to be written. However it is not written because the connection is TCP congested. When another idle timeout period elapses, it is then supposed to hard close the connection, but it delegates to the HTTP/2 session which reports that it has already been closed so it does not attempt to hard close the connection. This leaves the connection in ESTABLISHED state (i.e. not closed), TCP congested, and idle. An attacker can cause many connections to end up in this state, and the server may run out of file descriptors, eventually causing the server to stop accepting new connections from valid clients. The client may also be impacted (if the server does not read causing a TCP congestion), but the issue is more severe for servers. Patches Patched versions: 9.4.54 10.0.20 11.0.20 12.0.6 Workarounds Disable HTTP/2 and HTTP/3 support until you can…
Recommended action: Upgrade to 12.0.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.