Go 1.27.2 repairs HTTP connection state and resource accounting
October's security release fixes CONNECT desynchronization, an HPACK race, and HTTP/2 resource-limit bypasses. The mechanisms explain why connection lifetime and shared accounting belong in the same security review.
A connection returned to a pool can carry the wrong protocol state into its next request. Go 1.27.2 repairs two CONNECT cases where peers could disagree about how to interpret subsequent bytes. The October 8 release history lists security fixes across the toolchain and several packages. The announcement identifies fifteen fixes and publishes Go 1.26.9 alongside it.
The HTTP changes are particularly useful to study together. They concern connection reuse and shared state, including a compression encoder and flow-control counters. I value Go's readable concurrency model, but these reports show why readability has to extend to ownership. A field can be easy to find while the rules governing who may change it remain wrong.
Rejected CONNECT requests could poison a pooled connection
The client-side CONNECT report, CVE-2026-56866, describes http.Transport sending a nonempty request body after CONNECT headers without framing. CONNECT requests do not have that request body. If the server rejected the request with a persistent non-2xx response, the transport could put the connection back in its idle pool.
The server could interpret the trailing bytes as another HTTP request. A later caller reusing the connection could then receive the response to those bytes. In a reverse proxy with a shared transport, the report identifies cross-user response poisoning as a possible consequence. The mistake is in the relationship between requests on one connection, so looking at the first response alone does not describe the failure.
The fix closes an HTTP/1 transport connection after sending CONNECT regardless of response status. httputil.ReverseProxy also rejects incoming CONNECT with status 405. The issue explains that ReverseProxy never converted those connections into useful bidirectional tunnels. This is a deliberate end to a misleading apparent capability, supported by the handler's actual behavior.
Successful CONNECT changes the protocol contract
The server-side report, CVE-2026-94439, concerns a handler returning a 2xx CONNECT response without hijacking the connection. Go could continue serving HTTP requests on that connection. An intermediary could regard the connection as a tunnel while the backend still regarded its bytes as HTTP, creating a potential request-smuggling condition.
The HTTP/1 server now closes the connection after responding to CONNECT, regardless of status. The client and server corrections address different histories, but both prevent continued HTTP use after a transition the implementation cannot handle safely. A status code does not by itself establish that every participant agrees about what the following bytes mean.
This is the aspect of protocol implementation that interests me most. Correctness belongs to the sequence of states, not just the parsing of each message. A reusable transport needs evidence that the next request starts from a state both sides understand. When that evidence is absent, closing the connection gives subsequent work a defined starting point.
HPACK updates need the encoder's execution context
The HPACK race, CVE-2026-97032, involves two HTTP/2 goroutines modifying the same encoder without synchronization. One encodes response HEADERS. Another processes a client's SETTINGS_HEADER_TABLE_SIZE change. Repeated requests and table-size changes could crash the server.
Go now buffers the requested table-size change and applies it immediately before the server next writes a frame. The correction changes when shared state mutates. Receiving the request for a new size does not require mutating the encoder in the reader's execution context. The write path can apply the change at a point consistent with its use of the encoder.
That mechanism is more informative than describing the patch as adding thread safety. It identifies the owner of a state transition and moves the mutation to that owner. The resulting code can still respond to peer settings while avoiding concurrent changes to the same compression state.
Resource credits must be returned once
The flow-control defect, CVE-2026-78663, could return connection-level credit twice for the same buffered data. Resetting a stream returned credit for unread bytes. A handler reading those bytes could return credit again. A malicious client could consequently bypass MaxReceiveBufferPerConnection.
The report preserves an important limit. Concurrent stream limits and per-stream flow control still bounded total buffered data. This was a bypass of connection-level accounting, not a claim that every memory bound disappeared. The fix waits until the request handler finishes before refunding connection credit for a reset stream.
The underlying invariant is straightforward even though the execution paths differ. One set of bytes must not produce two refunds. Stream cancellation and handler completion both affect the same resource, so their interaction belongs in the accounting design. Testing either event alone cannot establish that the combined history preserves the limit. A regression fixture needs buffered data that remains available to the handler after the reset, because that is the overlap between the two refund paths.
Control messages and range counts also consume work
The initial-window-size issue, CVE-2026-78669, allowed an HTTP/2 peer to combine many streams with repeated small SETTINGS frames. Changes to the initial window caused work proportional to stream count. Both client and server now handle each change in constant time. This prevents an inexpensive control-message sequence from repeatedly causing work across the stream population.
The Range-header issue, CVE-2026-78667, concerns many small ranges passed to file-serving helpers. Those helpers now ignore a Range header containing more than 200 ranges. httpservecontentmaxranges controls the limit, and setting it to zero disables it. The correction establishes a bound on the number of requested ranges instead of treating syntactically valid range text as sufficient reason to process every entry.
These changes matter to servers that accept ordinary clients as well as explicitly hostile ones. Protocol features create work before an application handler makes its own policy decision. The corrected implementations give shared transport state and resource limits enforceable meanings across those earlier operations. For a deployment record, the relevant evidence is which rebuilt applications contain the fixes and which connection-handling roles those applications perform.