XT.PT Go security → This story
XT.PT
⌕
News Go security

Go 1.27.2 and 1.26.9 fix 15 vulnerabilities, seven of them in HTTP/2 and CONNECT handling

Go 1.27.2 and 1.26.9 fix five HTTP/2 flaws (also patched in golang.org/x/net v0.60.0), two CONNECT desync bugs, and issues in cmd/go, html/template, crypto/tls and os.

Filed09 Oct 2026, 07:57 UTC Length5 min · 823 words ReportingPrelo
go 1.27

Go 1.27.2 and Go 1.26.9 shipped on October 8. The Go release history lists security fixes "to the go command, and the crypto/tls, html/template, net/http, net/textproto, and os packages." The Go vulnerability database, updated the same day, carries 15 new standard-library and toolchain entries fixed in those two releases. Seven of them sit in two places: the HTTP/2 implementation and the handling of HTTP/1 CONNECT.

HTTP/2: five denial-of-service and smuggling fixes

All five HTTP/2 entries are fixed in Go 1.26.9 and 1.27.2, and in golang.org/x/net v0.60.0 for programs that import golang.org/x/net/http2 directly.

  • GO-2026-6617 (CVE-2026-97032), a server crash. The server modified its HPACK encoder "from two goroutines without synchronization": one encoding a response's HEADERS frame, the other resizing the table on a client SETTINGS_HEADER_TABLE_SIZE. "A malicious client can repeatedly send a request while changing the header table size to crash the server."
  • GO-2026-6603 (CVE-2026-78659), memory exhaustion via Trailer. A client's Trailer header populates Request.Trailer, a map, and a large declared field list let it allocate memory "while bypassing Server.MaxHeaderValueCount and Server.MaxHeaderBytes limits." The entry says HTTP/1 servers are not affected.
  • GO-2026-6612 (CVE-2026-78663), double flow-control refund. Connection-level flow control could be refunded twice for the same data, letting a client exceed MaxReceiveBufferPerConnection.
  • GO-2026-6611 (CVE-2026-78669), CPU via SETTINGS. Many small SETTINGS_INITIAL_WINDOW_SIZE frames across many streams cause "excessive CPU consumption in the client or server."
  • GO-2026-6610 (CVE-2026-78660), lax framing headers. The entry is unusually frank: "Historically, we have been rather lax about malformed framing-related headers in our HTTP/2 implementation." When Go acts as a reverse proxy, those headers could be forwarded to an HTTP/1 client, and "if the HTTP/1 client also does not behave strictly enough, this can result in response smuggling."

One detail in the affected-package data is worth knowing if you run govulncheck: for Go 1.26 the vulnerable code is listed under net/http, while for Go 1.27 it is listed under net/http/internal/http2. Same bugs, different symbol paths depending on your toolchain.

CONNECT: one bug on each side

Two entries cover the same verb from opposite ends.

On the client side, GO-2026-6605 (CVE-2026-56866): when http.Transport sent an HTTP/1 CONNECT with a non-empty body and the server rejected it with a non-2xx keep-alive response, the connection went back to the idle pool with the body bytes still on the wire. The server could read them as a pipelined request, so the next caller reusing the connection reads the wrong response. The advisory names the exposure: "In reverse proxies (including httputil.ReverseProxy) that forward CONNECT requests through a shared Transport, this can lead to cross-user response poisoning."

On the server side, GO-2026-6613 (CVE-2026-94439): after a handler answered CONNECT with a 2xx and returned without hijacking, the server "improperly continues to read and serve requests from the connection." The entry describes the impact as "mostly limited to potential request smuggling, where an intermediate proxy considers the data on the connection to be tunneled and the server considers it to be HTTP."

The other eight

  • cmd/go, two checksum bypasses (GO-2026-6601, GO-2026-6602). Both require a user working inside a malicious project and using a malicious GOMODPROXY; one concerns the bundled golang.org/fips140 module, the other golang.org/toolchain, which "now always goes to the network for the canonical checksum."
  • html/template, two escaping fixes (GO-2026-6599, GO-2026-6600): context tracking across consecutive expressions in a JavaScript template literal, and yield not being recognized as a keyword that precedes a regular expression.
  • crypto/tls (GO-2026-6607): multiple ECH outer extension references, "not permitted under RFC 9849," could trigger server memory exhaustion; they are now rejected as malformed.
  • net/http Range parsing (GO-2026-6609): many small ranges could make FileServer, ServeContent and ServeFile "consume an excessive amount of CPU."
  • net/textproto and mime/multipart (GO-2026-6608): a multipart part could read "an arbitrarily long line into memory when the remaining limit at the start of a part is less than 400 bytes."
  • os on Windows (GO-2026-6604): Root.Mkdir and Root.MkdirAll could follow a junction and create a directory outside the root, but only when the last path component is the junction.

What to do

Rebuild with Go 1.27.2 or 1.26.9; the fixes are in the standard library, so updating go.mod dependencies alone does nothing for binaries built with an older toolchain. If your code imports golang.org/x/net/http2 directly, also move to golang.org/x/net v0.60.0. Priorities are clear from the list: anything serving HTTP/2 to the internet, and any reverse proxy that forwards CONNECT or fronts HTTP/1 clients with an HTTP/2 upstream.

Primary sources: Go release history, Go vulnerability database entries GO-2026-6603, GO-2026-6605, GO-2026-6610, GO-2026-6613, GO-2026-6617 and the other ten listed above, golang-announce, read 2026-10-09.

Corrections and source documents: contact the desk
Read next →
Read next
Agent sandboxing · 5 min

Microsoft's MXC agent sandbox reaches 1.0, and the warning not to treat it as a security boundary is gone

Windows · 4 min

Windows 11 26H2 is out, and its worst known issue comes from a domain setting it starts to honor