Software Engineering Institute

Statement Date:   August 12, 2025

Vendor Statement

Digi International has reviewed the recently disclosed HTTP/2 stream reset vulnerability, in which client-triggered server-sent stream resets can cause excessive server resource consumption and potentially lead to denial-of-service (DoS). This vulnerability arises when attackers open multiple streams and rapidly reset them, often through malformed frames or flow control errors, exploiting discrepancies in stream accounting between protocol specifications and certain HTTP/2 implementations. Although streams may be marked as closed at the protocol level, backend processing can continue, allowing an unbounded number of concurrent streams to be processed over a single connection.

After thorough evaluation, Digi International confirms that our products and services are not vulnerable to this CVE. Our HTTP/2 implementations do not exhibit the incorrect stream accounting behavior required for exploitation and therefore are not susceptible to this denial-of-service condition. We will continue to monitor developments and update our security advisories should new information arise.

Statement Date:   August 28, 2025

Vendor Statement

No HTTP/2 implementations are shipped with eCosPro RTOS

Statement Date:   August 12, 2025

Vendor Statement

After testing this issue we found Envoy to not be vulnerable as the mitigations we added for "rapid reset" also prevent this newer vulnerability from being exploited.

As our mitigation for rapid reset was implemented in Envoy's HTTPConnectionManager it should cover all codecs.

Envoy security team.

Statement Date:   July 30, 2025

Statement Date:   June 25, 2025

Vendor Statement

I do not believe Go's net/http package is affected by this attack.

The mitigation in net/http for the Rapid Reset attack was to cap the number of requests which will be handled concurrently, to queue requests over that cap, and to close connections where the queue length exceeds the cap by too much.

Since this mitigation only takes into account the number of concurrently executing handlers and the number of queued requests waiting for a handler, it does not depend on the mechanism used to reset streams. It doesn't matter whether the client sends an explicit reset or induces the server to issue a reset.

Statement Date:   July 30, 2025

Vendor Statement

We have thoroughly investigated the matter and similarly as with other RESET_STREAM based attacks, we are not vulnerable for this particular type of attacks. Streams are counted and closed as soon as RST is seen in any direction and we also enforce the limit based on allocated streams. We also have glitches mechanism which detects and kills faulty connections depending on the configurable threshold.

Statement Date:   June 12, 2025

Vendor Statement

This is not a vulnerability in the HTTP protocol, but instead an implementation issue. We understand that there is a strong incentive for researchers to identify protocol flaws, but that characterisation is not justified in this case.

Implementations that are deployed in adversarial conditions need to anticipate abuses including denial of service. While protocol design can help to mitigate these attacks, there is no inherent flaw preventing implementations from correctly defending them. Indeed, HTTP/2's enablement of high concurrency (an explicit design goal of the protocol) makes it necessary for implementations to consider and actively handle such situations.

Furthermore, HTTP/2 goes to great lengths to document denial of service considerations: https://datatracker.ietf.org/doc/html/rfc9113#section-10.5

Including noting that "An invalid request (or server push) can cause a peer to send RST_STREAM frames in response."

Statement Date:   September 09, 2025

Vendor Statement

We have not received a statement from the vendor.

References

• https://gitlab.isc.org/isc-projects/bind9/-/issues/5325

Statement Date:   August 13, 2025

Vendor Statement

The Juniper SIRT is not aware of any Juniper Networks products or platforms that are vulnerable to this issue.

Statement Date:   August 07, 2025

Vendor Statement

lighttpd is not directly vulnerable to HTTP/2 MadeYouReset. lighttpd tracks request streams with connections to backends, makes a single request on each backend socket connection, and closes the socket (or kill()s the CGI) when the request stream is reset.

Statement Date:   August 08, 2025

Vendor Statement

We simulated an attack, and our LiteSpeed servers quickly blocked it due to the aggressiveness of the HTTP/2 behavior. Before blocking the client, LiteSpeed’s memory usage was not affected. This is mainly because of LiteSpeed’s efficient stream life cycle and memory management. Resources are promptly released when streams are reset, even in cases where a quick blocking is not triggered.

We are confident that MadeYouReset attacks cannot cause any trouble with LiteSpeed’s HTTP/2 implementation.

Statement Date:   July 28, 2025

Vendor Statement

The Node.js team does not consider it as a vulnerability for the reasons expressed in the original report on HackerOne.

Statement Date:   May 28, 2025

Vendor Statement

The Rust Programming Language does not ship an HTTP implementation in its standard library.

Statement Date:   August 21, 2025

Statement Date:   August 18, 2025

Vendor Statement

The X.Org Foundation does not ship any implementations of the HTTP/2 protocol.