Go: fifteen fixes in one release

On 8 October 2026 the Go team released Go 1.27.2 and 1.26.9 with fifteen security fixes at once. Go does not publish severity ratings, so the grouping below is ours: it sorts the fixes by what they let an attacker do.

Figure 1. Fifteen fixes, grouped by what they allow.

What was fixed

Crash or exhaust resources (7). HTTP/2 handling, range requests, multipart parsing and TLS Encrypted Client Hello. A crafted request makes a server use huge memory or stop. Cheap for the attacker, painful for you.
Smuggling and mix-ups (3). A reverse proxy that reuses a connection after a rejected CONNECT can leave bytes behind, so a reply nobody asked for lands on the next user. Header handling when converting HTTP/2 to HTTP/1 can also be abused.
Supply-chain checksum bypass (2). The go command, together with a malicious module proxy, could be tricked into accepting content that should have failed its checksum.
Template escaping (2). html/template could mis-escape in some JavaScript contexts, a route to cross-site scripting.
Escaping the root directory (1). On Windows, directory junctions could let code step outside a restricted root.

What could happen to your code

Go compiles the standard library into your binary. That means updating Go on your laptop fixes nothing that is already deployed. A service built last month still has last month’s HTTP/2 code. If it faces the internet, it can be knocked over by a request that the newer version handles.

The proxy mix-up deserves attention if you run anything that forwards traffic: a reply meant for one person arriving at another is a privacy incident, not just a bug.

What to do

Update the toolchain in every place Go is installed: laptops, CI images, base images. Use the latest patch of a supported line. At the time of writing that is 1.27.3 (or 1.26.10), which also carries the certificate change described in the next post.
Set the go directive and toolchain consistently in each module so builds are reproducible.
Rebuild and redeploy every service, then confirm the version with go version -m ./your-binary.
Run govulncheck ./... in CI so known issues in your dependencies show up as failures, not surprises.
Put request size, time and concurrency limits in front of public services. They blunt every resource-exhaustion bug, known or not.
Use a trusted module proxy and keep GONOSUMDB and GOFLAGS=-insecure out of your settings.

Go Security