Go 1.25.6 release notes: the boring patch that is not boring

I’ve watched teams ignore “dot-six” releases, then spend a Friday night chasing a security bulletin they could’ve avoided. Go 1.25.6 landed on 15 Jan 2026 and it ships security fixes, not just housekeeping. Four CVEs. Two denial-of-service vectors. One arbitrary code execution path. This is the kind of patch you apply now, not “when we get around to it.”

What actually changed in Go 1.25.6

The release tag only bumps the VERSION file, but the release branch includes backported security fixes you will feel if you run CI, parse ZIPs, terminate TLS, or use cgo.

CVE-2025-61731: Arbitrary code execution via cmd/go

This is the worst one. Usage of CgoPkgConfig allowed execution of the pkg-config binary with flags that weren’t explicitly safe-listed. An attacker who can influence your build inputs (think: a malicious module you go get) could potentially execute arbitrary code during the build. The fix sanitizes compiler flags from CgoPkgConfig before invoking pkg-config.

Reported by RyotaK of GMO Flatt Security Inc. If you build code from untrusted sources — CI systems processing external PRs, automated dependency updates, anything that pulls modules you don’t fully control — treat this as urgent.

CVE-2025-61726: Memory exhaustion in net/http ParseForm

When parsing a URL-encoded form, net/http could allocate an unexpected amount of memory when provided a large number of key-value pairs. A single malicious request could exhaust your server’s memory. Classic denial-of-service vector.

Reported by jub0bs. If any of your services expose HTTP endpoints that accept form data from the public internet, this one matters immediately. A load balancer won’t save you — the allocation happens before your handler code even runs.

// The fix limits internal allocations during form parsing.
// Before 1.25.6, a request with millions of key-value pairs
// would allocate proportionally. Now it won't.
// No code changes needed on your end — just upgrade.

CVE-2025-61728: ZIP archive denial of service

archive/zip used a super-linear file name indexing algorithm triggered the first time a file in an archive is opened. A maliciously constructed ZIP archive could exploit this for denial of service.

Reported by Jakub Ciolek. This affects CI systems, artifact pipelines, and any service that processes user-uploaded ZIP files. If you run a build system that unpacks archives, you’re in the blast radius.

CVE-2025-68121: TLS session resumption bypass

Two related issues in crypto/tls:

• Config.Clone shared session ticket keys: When you cloned a TLS config that had auto-generated session ticket keys, the clone shared those keys with the original. Sessions created with one config could resume on the other, even when your security design intended separate session domains. The fix stops Clone from copying auto-generated keys (explicitly set keys are still copied).
• Expired certificate chain ignored: Server-side session resumption only checked the leaf certificate’s expiration, not the full chain. If an intermediate or root certificate expired, sessions could still resume. Now the full chain is validated.

Reported by Coia Prant, with additional investigation by the Go Security team. If you use TLS session tickets in a multi-tenant or security-sensitive context, this is the one that matters to you.

Should you upgrade?

Yes. Not “probably.” The cmd/go arbitrary code execution alone makes this a must-upgrade for anyone running CI pipelines. Here’s the decision tree:

• Upgrade immediately if you expose HTTP endpoints: The ParseForm memory exhaustion (CVE-2025-61726) is exploitable with a single request. No authentication required.
• Upgrade immediately if you build from untrusted sources: The cmd/go code execution (CVE-2025-61731) affects any build that pulls external modules.
• Upgrade immediately if you process ZIP uploads: CI systems, artifact services, and import pipelines hit archive formats all the time.
• Upgrade on a short schedule if you only build trusted code: The TLS session resumption fix (CVE-2025-68121) is lower urgency but still a correctness issue.

I don’t trust “known issues: none” from any project. I trust “we tested it in staging with our own workload.”

How I’d roll this out in a real pipeline

This bit me when we upgraded Go in a container fleet and forgot we pinned different Go versions in two CI runners. Builds “worked,” but cache behavior went sideways and everyone blamed the code.

Step 1: Inventory your Go versions

Check developer laptops, CI images, and build containers. You’d be surprised how many places Go hides.

# Check every place Go might be running
go version                           # local
docker run --rm golang:1.25 go version  # container base image
ssh ci-runner-01 "go version"        # CI runners

# If you use go.mod toolchain directives, check those too
grep "^toolchain" go.mod

Step 2: Upgrade from official downloads

Use go.dev/dl for your OS. If you use a distro package, expect lag and confirm you actually got go1.25.6.

# Download and install (Linux amd64)
wget https://go.dev/dl/go1.25.6.linux-amd64.tar.gz
sudo rm -rf /usr/local/go
sudo tar -C /usr/local -xzf go1.25.6.linux-amd64.tar.gz
go version  # verify: go1.25.6

# For Docker builds, update your base image
FROM golang:1.25.6-alpine AS builder

Step 3: Validate with one boring build

# Run the standard validation
go test ./...
go build ./...
go mod tidy
git diff  # confirm no surprise changes to go.sum

# If you use cgo (relevant to CVE-2025-61731)
CGO_ENABLED=1 go build ./...

Step 4: Watch for cache weirdness

If builds act flaky after the upgrade, clear the cache and rerun once. I usually start with go clean -cache in the first job that upgrades.

# Nuclear option for CI
go clean -cache -testcache
go test ./...

If your team treats Go upgrades as “someone else’s problem,” make this one a calendar event, not a hero moment.

Go 1.25.6 vs Go 1.26: What’s the upgrade path?

Go 1.26 dropped on Feb 10 with the Green Tea GC, goroutine leak detection, and 30% faster cgo. If you’re on 1.25.x, the question is: patch to 1.25.6 now, or jump to 1.26?

The answer is both, in order. Patch to 1.25.6 today (security), then plan your 1.26 migration over the next sprint. The security fixes in 1.25.6 aren’t all backported to 1.26.0 — different branch, different timeline. Don’t assume 1.26 includes everything from 1.25.6 without checking.

Known issues and references

The upstream announcement does not list known issues for Go 1.25.6. The four CVEs addressed:

• CVE-2025-61731 — cmd/go arbitrary code execution via CgoPkgConfig
• CVE-2025-61726 — net/http ParseForm memory exhaustion
• CVE-2025-61728 — archive/zip denial of service
• CVE-2025-68121 — crypto/tls session resumption bypass

Official release: github.com/golang/go/releases/tag/go1.25.6 | Security announcement: golang-announce

Keep Reading

• Go Release History — Full timeline of every Go release with breaking changes and security fixes
• Node 20 vs 22 vs 24: Which LTS Should You Run? — Same “boring but important” upgrade decision for the Node.js ecosystem
• TypeScript 7.0 Goes Native in Go — How Go is reshaping the TypeScript compiler from the ground up

Related Reading

• How to Upgrade Rust Safely — Without breaking CI
• Docker vs Kubernetes in Production (2026) — The deployment decision
• How to Add Version Health Badges — Track release health in your README
• All Tools EOL Calendar — Track EOL dates across 30+ technologies