Live › vulnerability › CVE-2026-78663
Go to dashboardGo's net/http HTTP/2 server refunds connection-level flow control twice for the same data when a client resets a stream and the handler later reads it. A remote client can use this to exceed the configured MaxReceiveBufferPerConnection limit and consume more server memory than intended.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 19:13 UTC, 0h before NVD. All times on this page are UTC.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| stdlib | go | < 1.26.9 | 1.26.9 |
| stdlib | go | >= 1.27.0-0, < 1.27.2 | 1.27.2 |
| golang.org/x/net | go | < 0.60.0 | 0.60.0 |
Run go version on the build and runtime hosts and check whether it is below 1.26.9 or in 1.27.0 through 1.27.1; for vendored dependencies, check whether golang.org/x/net is below 0.60.0 in go.sum.
Upgrade the Go toolchain to or , and upgrade golang.org/x/net to , then rebuild and redeploy.
1.26.91.27.20.60.0Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-78663")
Go Vulnerability Database, CC-BY 4.0 · EPSS scores by FIRST, used with attribution · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.