Go HTTP/2 CVE-2026-78663

Exploitation requires the target to run Go's HTTP/2 server (net/http with h2, or golang.org/x/net/http2) with connection-level flow control active via MaxReceiveBufferPerConnection - the exact setting the bug defeats. The attacker must be able to open HTTP/2 streams, send data, and reset streams before the request handler reads the buffered bytes, which is the specific condition that produces the double refund. No authentication or user interaction is needed (PR:N/UI:N). Practical impact is LIMITED because the description states total buffered data is still bounded by the concurrent stream limit and stream-level flow control, so the bypass cannot grow memory usage without limit; servers not using HTTP/2 are unaffected.

Signals conflict and must be weighed carefully. The published CVSS of 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H) reflects a remotely reachable, low-complexity, unauthenticated flaw, and CISA SSVC rates it Automatable=yes with Technical Impact=total - both of which argue for prompt attention. However, EPSS is only 0.25% (15th percentile), there is no CISA KEV listing (SSVC Exploitation=none) and no public exploit identified, so there is no evidence of real-world weaponization. More importantly, the description itself constrains the impact: the double flow-control refund lets a client bypass the per-connection MaxReceiveBufferPerConnection limit, but 'total buffered data is still limited by the concurrent stream limit and stream-level flow control,' which caps the achievable resource abuse. This tension - a 9.1 'high integrity/high availability' vector versus a description that reads as a bounded resource-accounting bug (CWE-675, duplicate operations on a resource) - suggests the headline score likely overstates the practical impact. Net assessment: a legitimate bug worth patching in the normal cycle given how broadly Go's HTTP/2 stack is deployed, but not an emergency; the I:H and A:H designations are not well supported by the vendor's own bounding language and should be verified.

A remote attacker opens an HTTP/2 connection to a Go-based server, sends data on multiple streams, and resets each stream before the handler reads the buffered bytes, causing the server to credit connection-level flow control twice for the same data. Repeating this lets the client send more in-flight data than the configured MaxReceiveBufferPerConnection should allow, driving excess memory buffering per connection. No public exploit code has been identified, and realistic impact is capped by the concurrent-stream and stream-level flow-control limits.