Press enter or click to view image in full size

Go

Golang

Cybersecurity

Backend Development

DevOps

Go’s October Security Releases: Why Upgrading Go Isn’t Enough Until You Rebuild

Ascendrix Technologies

5 min read

·

5 days ago

--

Listen

Share

If you run Go services in production, October brought two security releases worth acting on:

• Go 1.27.2 and 1.26.9, released October 8, 2026, with security fixes to the go command and the crypto/tls, html/template, net/http, net/textproto, and os packages.
• Go 1.27.3, released October 19, 2026, with a security fix to crypto/x509 that distrusts a handful of compromised intermediate certificates.

Most of the fixes target HTTP/2 and HTTP/1 handling in net/http, the code that powers most Go web servers, APIs, and proxies.

But there’s an important detail that’s easy to miss in Go: installing a new Go version doesn’t fix anything already running. Here’s what was fixed, why rebuilding matters, and how to check your services.

What was fixed

The October 8 releases address a long list of issues, including:

HTTP/2 (server and client):

• Memory exhaustion from Trailer headers on HTTP/2 servers
• Server crash from a race condition in the HPACK header encoder
• Excessive CPU use from repeated changes to the initial window size
• Double flow-control refunds on HTTP/2 server streams
• The HTTP/2 transport accepting malformed framing headers

HTTP/1:

• Connection desynchronization on the client after a rejected CONNECT request
• Connection desynchronization on the server after a successful CONNECT response
• No limit on the size of parsed Range headers

Other packages:

• crypto/tls: rejecting malformed Encrypted Client Hello (ECH) extension references
• net/textproto and mime/multipart: a way to bypass the memory limit on MIME headers
• Fixes in html/template, os, and the go command

Then on October 19, Go 1.27.3 fixed CVE-2026–111943 in crypto/x509 by distrusting a handful of compromised intermediate certificates, so Go programs no longer trust certificates issued through them.

Many of these are denial-of-service issues: an attacker sends crafted requests that make your server use too much memory or CPU, or crash. For internet-facing services, that’s a real risk.

The Go-specific catch: you must rebuild

In many languages, updating the runtime updates every app that uses it. Go is different. The standard library, including net/http and crypto/tls, is compiled into your binary.

That means:

• Updating Go on your laptop or CI runner doesn’t change binaries already built or deployed.
• A service built last month with Go 1.27.1 still contains the vulnerable code, even if your server now has Go 1.27.3 installed.
• The fix only reaches production when you rebuild with the new toolchain and redeploy.

You can check which Go version built any binary:

go version ./myservice

And for more detail, including module versions:

go version -m ./myservice

If it shows go1.27.2 or earlier on 1.27 (or go1.26.8 or earlier on 1.26), the binary needs a rebuild.

Step 1: Update your toolchain

Check your current version:

go version

You want Go 1.27.3 on the 1.27 line, or the latest 1.26 patch if you’re still on 1.26. Check the official Go release history page for the newest 1.26 release.

To pin the toolchain for your project, so everyone and every CI run uses the same patched version:

go get toolchain@go1.27.3

This adds a toolchain line to your go.mod, and Go downloads the right version automatically when needed.

Docker: update the base image in your build stage, for example:

FROM golang:1.27.3 AS build

Step 2: Update golang.org/x/net if you use it

Several HTTP/2 fixes also apply to golang.org/x/net, which some projects use directly or indirectly. Version v0.60.0 includes the fixes, and it requires Go 1.26 or newer:

go get golang.org/x/net@v0.60.0
go mod tidy

Step 3: Run govulncheck

govulncheck is the official Go vulnerability scanner. What makes it especially useful is that it checks whether your code actually calls the vulnerable functions, so it reports real exposure, not just every vulnerable package in your dependency tree.

go install golang.org/x/vuln/cmd/govulncheck@latest
govulncheck ./...

You can also scan a built binary directly, which is useful for checking what’s actually deployed:

govulncheck -mode=binary ./myservice

Step 4: Rebuild, redeploy, and verify

Rebuild every service with the patched toolchain, deploy it, and confirm with go version ./myservice that the running binaries were built with the new version.

Don’t forget less obvious Go binaries:

• Internal tools and CLIs your team distributes
• Sidecars, operators, and controllers in Kubernetes
• Third-party Go tools you run in production. Check whether their maintainers have released new builds.

Step 5: Watch for tooling surprises

One project upgrading to Go 1.27 found that older golangci-lint versions couldn’t read Go 1.27’s compiled package data and had to upgrade golangci-lint as well. If your linters or other tools fail after updating Go, check for newer versions before assuming your code is broken.

Go 1.25 is out of support

Go supports only the two most recent major releases. With Go 1.27 out, Go 1.25 no longer receives security fixes, so it won’t get any of these patches. If you’re still on Go 1.25 or older, upgrade to Go 1.26 or, preferably, 1.27.

While you’re upgrading: what’s new in Go 1.27

If you’re moving to Go 1.27 for the first time, it’s one of Go’s most substantial releases in years:

• Generic methods: methods can now declare their own type parameters, a long-requested feature.
• encoding/json/v2 and encoding/json/jsontext are now available, and the new implementation becomes the default for JSON. If you hit compatibility problems, you can temporarily build with GOEXPERIMENT=nojsonv2.
• crypto/mldsa: post-quantum ML-DSA digital signatures, standardized in FIPS 204.
• A new built-in uuid package for generating and parsing UUIDs.
• An experimental, portable simd package for vector operations.
• The goroutine leak profile is now generally available, which helps find goroutines that never exit.
• Faster small memory allocations.
• New go fix modernizers to update older code patterns automatically.

Note that Go 1.27 needs macOS 13 Ventura or later on Macs.

Automate it

To stay on top of future releases:

• Add govulncheck to CI, so builds fail when reachable vulnerabilities appear.
• Use Dependabot or Renovate to update both Go modules and your Go toolchain version.
• Rebuild and redeploy regularly, not only when your own code changes. In Go, a security fix in the standard library only reaches production through a new build.

Practical recommendation

This week, for each Go service:

1. Run go version ./yourbinary on what’s deployed.
2. Update to Go 1.27.3 (or the latest 1.26 patch), and update golang.org/x/net if you use it.
3. Run govulncheck ./....
4. Rebuild and redeploy, then verify the deployed binary’s Go version.

Go makes deployment wonderfully simple: one static binary. The trade-off is that security fixes travel the same way, so no rebuild means no fix.

Sources: the Go release history on go.dev, the Go issue tracker for CVE-2026–111943, and October 2026 security update notes from Go projects on GitHub (uniqush-push, burrow, and websyncd), plus Go 1.27 release notes and coverage from JetBrains and daily.dev.