-------- Forwarded Message -------- Subject: [security] Vulnerabilities in golang.org/x/net Date: Thu, 8 Oct 2026 18:09:23 +0000 From: announce () golang org To: golang-nuts () googlegroups com

Hello gophers, net/http: HTTP/2 server memory exhaustion due to Trailer headers

When "Trailer" headers are sent by a client, the HTTP server internally uses the header values to populate the Request.Trailer map passed to the server handler. Because Request.Trailer is a map, each entry incurs memory overhead. For HTTP/2 servers, a malicious client can exploit this by sending a "Trailer" header that declares a large number of fields, causing the server to allocate a disproportionate amount of memory while bypassing Server.MaxHeaderValueCount and Server.MaxHeaderBytes limits. This exploit is not applicable for HTTP/1 servers, which do not support multiplexing a large number of requests over one TCP connection, and whose Server.MaxHeaderBytes are calculated differently.

Server.MaxHeaderValueCount and Server.MaxHeaderBytes limits are now applied towards the trailer fields declared in "Trailer" headers.

Thanks to RyotaK (https://ryotak.net <https://ryotak.net>) of GMO Flatt Security Inc. for reporting this issue.

This is CVE-2026-78659 and Go issue https://go.dev/issue/81857 <https://go.dev/issue/81857>.

net/http: excessive CPU consumption from repeated initial window changes

A malicious HTTP/2 peer could cause excessive CPU consumption in the client or server by opening a large number of streams and then sending many small SETTINGS frames containing SETTINGSINITIALWINDOWSIZE values.

The HTTP/2 client and server now efficiently handle changes to the initial window size (O(1) rather than O(number of streams)).

Thanks to Jakub Ciolek (https://ciolek.dev <https://ciolek.dev>) for reporting this issue.

This is CVE-2026-78669 and Go issue https://go.dev/issue/81742 <https://go.dev/issue/81742>.

net/http: double flow control refund on HTTP/2 server streams

The HTTP/2 server could 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 could exploit this to bypass the configured connection-level limited by the concurrent stream limit and stream-level flow control.

The HTTP/2 server now waits to refund connection-level flow control for reset streams until after the request handler is complete.

Thanks to Ali Sherif (https://www.linkedin.com/in/ali-sherif-13812b276/ <https://www.linkedin.com/in/ali-sherif-13812b276/>) for reporting this issue.

This is CVE-2026-78663 and Go issue https://go.dev/issue/81743 <https://go.dev/issue/81743>.

net/http: HTTP/2 server crash due to HPACK encoder race

HTTP/2 servers could end up crashing due to inadvertently modifying its HPACK encoder concurrently. This happens because the server modifies the HPACK encoder from two goroutines without synchronization: one uses the encoder to encode a HEADERS frame as part of a response sent to a client and the other modifies the encoder's table size when handling a SETTINGS frame containing SETTINGSHEADERTABLESIZE that a client sends. A malicious client can repeatedly send a request while changing the header table size to crash the server.

Fix this issue by not applying SETTINGSHEADERTABLESIZE immediately. Instead, buffer any SETTINGSHEADERTABLESIZE received, and only apply the new value prior to the next time the server writes a frame.

Thanks to RyotaK (https://ryotak.net <https://ryotak.net>) of GMO Flatt Security Inc. for reporting this issue.

This is CVE-2026-97032 and Go issue https://go.dev/issue/81867 <https://go.dev/issue/81867>.

Cheers, Go Security team

--

Due to missing nil check, sending 0x0a-0x0f HTTP/2 frames will cause a running server to panic