Go Security Releases, October 2026: 16 CVEs in Go 1.27.3 and 1.26.10, and Why Every Binary Needs a Rebuild

The Go team shipped two security releases in October 2026. Go 1.27.2 and 1.26.9 arrived on 8 October with fifteen fixes, most of them in net/http and its HTTP/2 implementation. Go 1.27.3 and 1.26.10 followed on 19 October with a single change to crypto/x509, a response to the eMudhra certificate compromise. None of the flaws is known to be exploited, but several let an unauthenticated client crash or slow down a Go HTTP server. There is also a catch that makes Go different from PHP or Java: installing the new Go version on a server fixes nothing by itself.

Updating Go Is Not Enough: Rebuild Every Binary

A Go program carries its own copy of the standard library. When you build a service, net/http, crypto/tls, and everything else it uses are compiled into the binary. A server running a binary built with Go 1.26.8 keeps the old net/http code no matter which Go toolchain is installed on that machine, and no operating system update will change it. The fix only reaches production when each service is rebuilt with the new toolchain and redeployed.

The same applies to tools you did not write. Plenty of infrastructure software is written in Go, including container registries, reverse proxies, monitoring agents, and command line tools. Each one is fixed only when its maintainers publish a build made with a patched toolchain. A public example from this month: the Docker distribution registry image was still being built with Go 1.26.8 after the security release, because the Dockerfile pinned the Go version.

To see which Go version built a binary, run go version followed by the path to the file. go version -m also lists the modules compiled into it. For a fuller check, govulncheck -mode=binary scans a compiled binary and reports which known vulnerabilities its code can actually reach.

Which Versions to Use

Go supports the two most recent major releases. Since Go 1.27 came out in August, Go 1.25 no longer receives security fixes. Services still built with it should move to 1.26 or 1.27, which for most code is a toolchain change rather than a rewrite.

Five HTTP/2 Server Flaws

The largest group of fixes is in HTTP/2. A Go HTTP server enables HTTP/2 automatically when it serves TLS, so any Go service that terminates HTTPS itself is exposed. A service that sits behind Nginx or a cloud load balancer and receives plain HTTP/1.1 is mostly shielded from these particular flaws, although it still needs the other fixes.

The crash in CVE-2026-97032 deserves the most attention. It needs no authentication and no special endpoint. Any HTTP/2 connection will do, and a process that crashes takes every request in flight with it.

Code that imports golang.org/x/net/http2 directly, rather than relying on the copy inside net/http, needs a separate update. The same fixes are in golang.org/x/net v0.60.0, so run go get golang.org/x/net@v0.60.0 or later and rebuild.

HTTP/1, Forms, and TLS

• CVE-2026-94439: when a handler answers an HTTP/1 CONNECT request with a 2xx status and returns without hijacking the connection, the server kept reading HTTP requests from what should have become a tunnel. Behind a proxy, that can lead to request smuggling.
• CVE-2026-56866: on the client side, http.Transport could leave a pooled connection out of sync after a rejected CONNECT request with a body, so the next request on that connection read the wrong response.
• CVE-2026-78667: a Range header with a large number of small ranges made FileServer, ServeContent, and ServeFile use excessive CPU. Services that serve files or downloads directly from Go are the ones affected.
• CVE-2026-94440: parsing a multipart form could read an arbitrarily long line into memory, bypassing the memory limit. Any endpoint that accepts file uploads or multipart forms is a candidate.
• CVE-2026-97031: a TLS client could send repeated Encrypted Client Hello outer extension references and drive up memory use in the server process.

Templates, Windows, and the go Command

Two fixes in html/template correct escaping inside JavaScript. One reset context tracking between consecutive expressions in a template literal (CVE-2026-94448), the other recognised the yield keyword before a regular expression (CVE-2026-97030). Both could leave a value unescaped in a script block, which is the kind of gap that becomes cross-site scripting. On Windows, os.Root.Mkdir and MkdirAll could follow a junction and create a directory outside the root (CVE-2026-56857). Two fixes in the go command close checksum bypasses for golang.org/fips140 and golang.org/toolchain (CVE-2026-94444 and CVE-2026-94447), which required a developer to work inside a malicious project and use a malicious module proxy.

The eMudhra Certificate Denylist

Go 1.27.3 and 1.26.10 contain one change, CVE-2026-111943. On most platforms Go uses the operating system trust store, so updated ca-certificates packages already remove trust in the compromised eMudhra intermediates. In some cases the system store is not updated without extra action, for example in minimal container images that copy a certificate bundle at build time. For those, crypto/x509 now carries a denylist and Verify returns an error for any of the known compromised intermediate certificates. There is no setting to turn it off. As with the other fixes, it only takes effect after a rebuild.

How to Roll It Out

1. 1List every Go binary running in production, including your own services, scheduled jobs, CLI tools in CI, and third-party software built with Go.
2. 2Run go version or govulncheck -mode=binary against each one to see which toolchain built it and which vulnerabilities are reachable.
3. 3Raise the Go version wherever it is pinned: the toolchain line in go.mod (for example with go get toolchain@go1.27.3), the golang base image in each Dockerfile, and the setup-go version in CI workflows.
4. 4Update golang.org/x/net to v0.60.0 or later if the module imports it, then run go mod tidy and the test suite.
5. 5Rebuild every image, redeploy, and confirm with go version -m that the running binary reports go1.27.3 or go1.26.10.
6. 6For third-party tools, upgrade to a release built with a patched toolchain, or ask the vendor when one will be available.

Teams that already run govulncheck in CI usually saw these fixes flagged within a day of release. If yours does not, this is a good moment to add it, together with a scheduled rebuild of base images, so the next Go security release becomes a routine pull request instead of a hunt. If you need help auditing or rebuilding Go services across your infrastructure, our managed service team can take it on, and our Golang training covers these practices for in-house teams.