Go x/net 0.60.0 patches HTTP/2 memory and CPU flaws

The Go project has released golang.org/x/net v0.60.0 to close three HTTP/2 weaknesses that could let a remote peer exhaust server memory, burn CPU, or sidestep connection flow-control limits.

The most severe, CVE-2026-78659, is a memory exhaustion bug in the HTTP/2 server path. When a client sends a Trailer header that names a huge list of fields, the server builds a Request.Trailer map entry for each name. That allocation sat outside Server.MaxHeaderValueCount and Server.MaxHeaderBytes, so a multiplexed attacker could force disproportionate memory use on a single connection. HTTP/1 servers were not exposed the same way. The fix applies those existing header limits to trailer field declarations as well. RyotaK of GMO Flatt Security Inc. reported the issue (Go issue 81857).

CVE-2026-78669 covers excessive CPU use on both clients and servers. An attacker could open many streams and flood small SETTINGS frames that repeatedly change SETTINGS_INITIAL_WINDOW_SIZE. Updating every stream on each change was costly; the stack now handles initial-window updates in constant time. Jakub Ciolek reported that flaw (Go issue 81742).

A third defect allowed an HTTP/2 server to refund connection-level flow control twice for the same data: once when the client reset a stream, and again when the handler later read buffered bytes. That double credit could let a client exceed MaxReceiveBufferPerConnection. The double refund is eliminated.

Operators who expose HTTP/2 with golang.org/x/net should move to v0.60.0.