Go 1.26.4 Release Notes: Patch releases lie, so read this twice

Another Go patch release. What broke this time, and why doesn’t the changelog say it plainly?

I have watched “maintenance” Go updates fail in two boring ways: a security fix forces an upgrade, then the toolchain tweak trips CI on one platform you forgot you still ship. Go 1.26.4 looks small, but it carries three CVE fixes plus a compiler correctness fix. That is not nothing.

Concerns first: what the official notes don’t spell out

It’s quiet.

That’s the problem. The upstream release info does not come with a friendly “here’s what will hurt you” section, and the tag commit message does not describe the actual risk surface. If you only skim and see “point release,” you will miss the security items and the compiler fix, and you will also miss the clue that this release cherry-picks a handful of targeted changes rather than shipping “no changes.”

• “Known issues: none” does not mean “safe”: It usually means nobody wrote them down. I do not trust “known issues: none” from any project.
• The release notes do not hand you a rollout plan: If you run Go across a fleet, you still need canaries, build matrix coverage, and a rollback path.
• Patch releases can change behavior without “new features”: A security hardening change can affect edge-case inputs, error strings, and validation logic. That can break tests that assert exact error text.

My default stance: wait a week unless you need the CVE fixes or you already sit on a policy that forces “latest patch.”

What actually changed in Go 1.26.4 (the parts that matter)

Here’s the short list.

Upstream’s compare between go1.26.3 and go1.26.4 shows a small set of cherry-picks. The important bits cluster around security and correctness. If you run internet-facing services or you parse user-controlled headers, you should care.

• Security fix (mime): Go patches CVE-2026-42504 by avoiding quadratic behavior in mime.WordDecoder.DecodeHeader. They claim it prevents pathological inputs from chewing CPU. I buy that, but you should still run a quick load test if your app decodes lots of MIME headers.
• Security fix (net/textproto): Go patches CVE-2026-42507 by escaping arbitrary input when it shows up in net/textproto error strings. If you assert exact error messages in tests or scrape logs downstream, expect noise.
• Security fix (crypto/x509): Go patches CVE-2026-27145 by avoiding repeated splitting during hostname checks in crypto/x509. This reads like “performance,” but performance bugs in cert verification show up as outages under handshake storms.
• Compiler correctness (amd64): Go fixes an amd64 misscompile involving an expression shaped like x+x<<63 being miscompiled to x<<0. If you do bit tricks in hot paths, you do not get to ignore this.
• runtime/race build (linux/arm64): Go adjusts race detector build artifacts for linux/arm64. If you run arm64 runners and rely on -race, this might be the only reason you upgrade.

So should you upgrade? My grudging recommendation

Probably.

If you run production Go services that touch the public internet, the CVEs push you toward upgrading sooner rather than later. If you run internal-only dev tooling and you have no policy pressure, you can probably wait a week, let the first wave of “this broke on Alpine” posts land, then move.

• Upgrade soon (this week) if: you care about the listed CVEs, you terminate TLS at the app, you parse MIME-ish inputs, or you ship to strict compliance environments.
• Upgrade after a short hold if: you have a large CI fleet, you pin toolchains tightly, or you have a history of “minor” Go bumps breaking CGO or platform builds.
• Do not overthink it if: this is a dev cluster or a personal workstation. Just install it, run tests, move on.

How I would roll this out (without pretending it’s risk-free)

Start small.

I usually do a two-stage rollout. First, I upgrade CI, because CI fails loudly. Then I canary prod, because prod fails expensively. Some folks skip canaries for patch releases. I don’t, but I get it if you run a tiny service and you can roll back fast.

• Step 1, install from upstream: Grab binaries from go.dev/dl. If you run an internal mirror, pull the tarballs there and record the SHA256 from the download page.
• Step 2, verify the toolchain: Run go version and confirm it prints go1.26.4. Then run go env and sanity-check GOOS, GOARCH, and any CGO flags your builds rely on.
• Step 3, smoke tests that catch dumb breakage: Run go test ./… plus your integration suite. If you ship linux/arm64, run at least one linux/arm64 build in CI even if you do not run tests there.
• Step 4, canary prod: Route 1% of traffic to services built with go1.26.4, watch p95 latency, error rate, and RSS. If you do not have those metrics, fix that first.
• Step 5, rollback plan: Keep the prior Go toolchain cached and keep your old build artifacts. If a build starts failing, you want “flip the version pin back” as a one-line change.

Known issues

Upstream doesn’t list any. That does not calm me down.

Other stuff in this release: a few more cherry-picks, some tooling glue, the usual. There’s probably a better way to decide “upgrade now vs wait” than my gut plus a canary, but I have not found it yet.

Official links

Use the upstream release tag and compare to audit what changed. Do not trust summaries, including mine, if you have a regulated environment.

• GitHub release tag: https://github.com/golang/go/releases/tag/go1.26.4
• Compare view (go1.26.3 to go1.26.4): https://github.com/golang/go/compare/go1.26.3…go1.26.4
• Downloads: https://go.dev/dl/
• Release history: https://go.dev/doc/devel/release