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.
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
Trailerheader populatesRequest.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_SIZEframes 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 maliciousGOMODPROXY; one concerns the bundledgolang.org/fips140module, the othergolang.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, andyieldnot 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/httpRange parsing (GO-2026-6609): many small ranges could makeFileServer,ServeContentandServeFile"consume an excessive amount of CPU."net/textprotoandmime/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."oson Windows (GO-2026-6604):Root.MkdirandRoot.MkdirAllcould 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.