Double HTTP/2 flow-control refund bypass in Go standard library net/http

The HTTP/2 server can refund connection-level flow control twice for the same data: Once when a client resets a stream (refunding data for any sent-but-unread portion of the stream), and again when a request handler reads the buffered data. A malicious client can exploit this to bypass the configured connection-level flow control limit (MaxReceiveBufferPerConnection). Total buffered data is still limited by the concurrent stream limit and stream-level flow control.

• net/http in the Go standard library: affected for semver versions from 0 through versions less than 1.26.9. The fix for this branch is included in 1.26.9. • net/http/internal/http2 in the Go standard library: affected from 1.27.0-0 through versions less than 1.27.2. The fix for this branch is included in 1.27.2. • golang.org/x/net/http2: affected for semver versions from 0 through versions less than 0.60.0. The corresponding fix is v0.60.0.

The record marks the default status as unaffected for the listed products. Unlisted parallel or later branches should not be assumed validated solely because another branch has a fix.

Go standard library net/http, net/http/internal/http2, and golang.org/x/net/http2 maintain connection-level and stream-level flow-control accounting for HTTP/2. When a client resets a stream, the server refunds connection-level flow-control credit for data that was sent but not read. If the request handler later reads the buffered data, the same data can be refunded again. This is a CWE-675 condition in which a resource is operated on multiple times in a context that expects a single operation.

Exploitation requires a malicious client to connect to an HTTP/2 server and create a case where a stream is reset while data remains buffered for the handler to read. The double refund can bypass MaxReceiveBufferPerConnection. Total buffered data remains limited by the concurrent stream limit and stream-level flow control, so the available evidence does not establish unbounded memory use. Go changed the behavior so that connection-level flow control for reset streams is refunded only after the request handler completes.

The flaw is remotely reachable through a malicious HTTP/2 client and does not require special privileges or user interaction. The server must provide HTTP/2 and process buffered stream data after a client resets the stream. The supplied record characterizes exploitation as low complexity, while concurrent-stream and stream-level controls still limit total buffered data. The supplied record sets public_exploit to false and known_exploited to null; those fields do not prove that exploitation is impossible.

The primary technical outcome is incorrect connection-level flow-control accounting, allowing a client to exceed the configured MaxReceiveBufferPerConnection threshold for buffered data. This can increase memory pressure, reduce request-processing capacity, and potentially interrupt service availability. The flaw requires no special privileges and affects the HTTP/2 service handling the attacker's connection. Concurrent-stream and stream-level flow-control limits still bound total buffered data, so the available evidence does not support a conclusion of unlimited resource consumption from one connection. The record does not establish impact beyond the affected server or document data disclosure or modification.

• Resource and availability risk: An HTTP/2 server may buffer more data than its connection-level flow-control configuration intends, increasing memory pressure and the risk of degraded performance or denial of service. • Exposure: Services accepting HTTP/2 connections from untrusted clients should be prioritized, especially when handlers read request bodies after stream-reset events. • Impact limit: The concurrent stream limit and stream-level flow control continue to bound total buffered data, so the available evidence does not show unbounded resource consumption. • Data and access: The supplied evidence focuses on a resource-control bypass and does not document data disclosure or data modification.

1. Upgrade the Go standard library on the 1.26 branch to 1.26.9, or on the 1.27 branch to 1.27.2, then rebuild and redeploy affected HTTP/2 services.
2. If the application directly imports golang.org/x/net/http2, update that dependency to v0.60.0.
3. Check both direct dependencies and code bundled into binaries or containers. Changing a source dependency without rebuilding and restarting the service does not confirm that the fix is active.
4. Verify each deployed branch against the boundaries in affected_summary; do not extend the conclusion from one fixed branch to another without supporting evidence.
5. The record does not provide a confirmed standalone workaround. Existing stream limits only constrain residual impact and do not replace applying the fixes.

1. Inventory Go binaries and services that provide HTTP/2 servers, and identify whether they use net/http, net/http/internal/http2, or the golang.org/x/net/http2 module.
2. Compare runtime versions, module dependencies, and image contents with the affected ranges and fixed releases listed in affected_summary.
3. Review handlers that read request bodies or buffered stream data after a client reset, because this behavior is directly relevant to the vulnerable sequence.
4. Review available HTTP/2 telemetry for unusual stream-reset activity combined with increasing memory use or buffered request-body counts. This is precautionary monitoring, not a confirmed indicator of compromise.
5. The absence of these patterns does not prove safety; deployed-version verification remains the decisive check.