Concurrent HPACK encoder race in Go standard library net/http and golang.org/x/net/http2 can crash HTTP/2 servers

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 SETTINGS_HEADER_TABLE_SIZE that a client sends. A malicious client can repeatedly send a request while changing the header table size to crash the server.

The record confirms these affected boundaries:

• Go standard library net/http: versions before 1.26.9.
• Go standard library net/http/internal/http2: from 1.27.0-0 through versions before 1.27.2.
• golang.org/x/net/http2: versions before 0.60.0.

Go documented the net/http fix in 1.26.9, the net/http/internal/http2 fix in 1.27.2, and tagged the golang.org/x/net fix as v0.60.0. The status of parallel or unlisted release branches should not be inferred from these fixes alone.

The flaw is caused by unsynchronized access to a shared HPACK encoder in an HTTP/2 server. One goroutine uses the encoder to encode a HEADERS frame in a response sent to a client, while another changes the encoder table size while processing a client-supplied SETTINGS frame containing SETTINGS_HEADER_TABLE_SIZE. This is a CWE-362 race condition affecting net/http, net/http/internal/http2, and golang.org/x/net/http2. The client controls the table-size setting and can combine repeated requests with changing values to trigger the race in an HTTP/2 server. The input is delivered over the network, but the record does not identify the exact panic, assertion, or code path that produces the crash. The documented fix delays applying SETTINGS_HEADER_TABLE_SIZE, buffers the received value, and applies it only before the next time the server writes a frame.

• The attack is reachable over the network against an affected HTTP/2 server.
• The supplied attack characteristics indicate that authentication is not required, user interaction is not required, and attack complexity is low.
• A malicious client can repeatedly send requests while changing SETTINGS_HEADER_TABLE_SIZE, creating contention with the server's encoding of response frames.
• The record marks public_exploit as false and provides no known-exploitation status. This does not prove that exploitation has never occurred outside the available evidence.

The flaw can let an unauthenticated network client crash an HTTP/2 server by triggering a race in the HPACK encoder. The documented technical result is loss of availability for the process or service, which can cause failed requests, terminated connections, and a need for restart or failover. The record does not identify privilege escalation, data access, or data modification; the direct impact is limited to availability. The practical outage depends on the deployment's recovery controls, failover design, and whether HTTP/2 is exposed to untrusted clients.

• A remote client can crash an HTTP/2 server process, interrupting or removing availability of services that depend on that process.
• If the service lacks effective restart or failover controls, repeated triggering can extend the outage and increase operational recovery effort.
• The documented effect is centered on availability; the record does not identify data disclosure or data modification caused by this flaw.
• Applications embedding HTTP/2 in reverse proxies, API servers, or internal services should be checked when they accept HTTP/2 connections from untrusted sources.

1. Upgrade Go standard library net/http to 1.26.9 for the affected branch.
2. Upgrade Go standard library net/http/internal/http2 to 1.27.2 for the affected branch.
3. Upgrade the golang.org/x/net/http2 dependency to v0.60.0.
4. Rebuild and redeploy binaries that use the affected packages, then verify that the running artifact is the updated build.
5. The available evidence does not provide a general operational workaround that replaces updating. Do not treat request limits or header configuration changes as a fix for this race unless the vendor supplies specific guidance.

1. Inventory Go binaries and dependencies that provide HTTP/2 servers, then inspect module manifests, vendor trees, and build metadata for net/http, net/http/internal/http2, or golang.org/x/net/http2.
2. Identify services that accept HTTP/2 connections from untrusted networks, especially services that can receive client SETTINGS frames.
3. Review crash dumps, panic reports, restart loops, and HTTP/2 connection errors that occur with repeated requests or changing SETTINGS_HEADER_TABLE_SIZE values. Treat these as triage clues, not as Go-confirmed indicators of compromise.
4. Compare the deployed artifact with the fixed release for the relevant package branch rather than checking only for a generic Go dependency.
5. Do not treat the absence of crash logs as proof that a system is unaffected. Complete the dependency and deployed-artifact checks.