On 14 August 2026 the Go team released Go 1.26.6 and Go 1.25.13, two minor point releases that fix 10 security issues. They span the standard library (net/http, crypto/tls, encoding/xml, encoding/asn1, net/url, html/template) and the golang.org/x modules (mod, net).
Go makes the reachability question easier than most ecosystems. The toolchain ships govulncheck, which reports only vulnerabilities whose affected symbols appear in your call graph. That is the angle worth using here, because several of these fixes are in packages a given binary may never import.
What's affected
Fixed in Go 1.26.6 and Go 1.25.13. The x/ fixes ship in module releases, so check your go.mod as well as the toolchain.
| CVE | Package | What it is |
|---|---|---|
| CVE-2026-56865 | x/mod/sumdb/tlog | A malicious GOPROXY could forge up to two sumdb tiles, letting a module bypass the GOSUMDB check and put attacker content in the module cache |
| CVE-2026-56864 | x/mod/sumdb | A malicious GOSUMDB could serve module content not contained in the transparency log, because unrelated unauthenticated hashes were accepted in Lookup |
| CVE-2026-56859 | encoding/xml | DecodeElement reset the depth counter so the guard never fired, allowing stack exhaustion |
| CVE-2026-56853 | net/http | The unencrypted HTTP/2 client preface check had no timeout. ReadHeaderTimeout now applies |
| CVE-2026-56860 | net/url | Resolving relative paths with dot dot segments had quadratic cost |
| CVE-2026-46600 | x/net/dns/dnsmessage | Parsing an invalid SVCB or HTTPS record could panic on buffer overflow |
| CVE-2026-56862 | crypto/tls | Handshake messages such as KeyUpdate counted as state advancing before the handshake finished, so a malicious client could force endless key derivation |
| CVE-2026-56858 | html/template | Pathological input could close an unescaped slash early in JavaScript regexp context, potentially enabling XSS |
| CVE-2026-39821 | x/net/idna | ToASCII and ToUnicode accepted Punycode labels that decode to ASCII only labels, which can matter to programs that check hostnames |
| CVE-2026-33818 | encoding/asn1 | Unmarshal had no recursion limit, so deeply nested input could exhaust the stack |
How to check if you're exposed
First, the toolchain that built each binary. Go embeds it:
go version -m ./your-binary | head -3
go version
Then run govulncheck against source and against built binaries. Source mode gives the call-graph answer.
go install golang.org/x/vuln/cmd/govulncheck@latest
govulncheck ./...
# or inspect a shipped binary
govulncheck -mode=binary ./your-binary
Read the output in two parts. Vulnerabilities listed under "Your code is affected" have a call path from your code to the affected symbol. Entries listed as present in imported packages but not called are lower urgency, though not zero, since code paths change.
For the x/ modules:
go list -m golang.org/x/net golang.org/x/mod
go mod why -m golang.org/x/net
Some quick reasoning on who is hit:
- Anything running
net/httpservers is in scope for the preface timeout issue (CVE-2026-56853), but only if it accepts unencrypted HTTP/2. - Anything terminating TLS in Go (
crypto/tls) is in scope for CVE-2026-56862. - Programs that render
html/templatewith JavaScript contexts can reach CVE-2026-56858. - The
x/mod/sumdbissues matter to tooling that talks to a proxy or checksum database, and to build systems that resolve modules from a GOPROXY you do not control.
What to do now
- Upgrade the toolchain to Go 1.26.6 or Go 1.25.13 and rebuild. A Go binary carries its standard library, so patching the host Go install does nothing for binaries already built.
- Bump
golang.org/x/netandgolang.org/x/modto the releases that carry the fixes, then rungo mod tidy. - Rebuild and redeploy every service, including sidecars and CLI tools you ship. Inventory what binaries you run, since there is no package manager step that updates them for you.
- Run
govulncheckin CI so the next advisory arrives with a call path attached. - Set
GOPROXYandGOSUMDBdeliberately in CI (see below).
How this could have been avoided
Two of these fixes concern the module supply chain, and the rest are parser and protocol hardening. Controls that map to how these bugs work:
- Run your own GOPROXY with a pinned GOSUMDB. CVE-2026-56865 and CVE-2026-56864 need a malicious proxy or checksum database in the path. A private proxy you operate, plus the default
sum.golang.orgverification, shrinks who can sit in that position. - Commit
go.sumand verify in CI withgo mod verify. A forged tile that lands bad content in the cache is caught if the cache is rebuilt from a verifiedgo.sum. - Set read header and idle timeouts on every
http.Server. The HTTP/2 preface bug is a missing timeout. ExplicitReadHeaderTimeout,ReadTimeoutandIdleTimeoutmake that class of slowloris style issue cheap regardless of the stdlib patch level. - Terminate TLS at a hardened edge and cap handshake work. A load balancer in front of the Go service absorbs the KeyUpdate loop in CVE-2026-56862 before it burns your CPU.
- Bound untrusted input depth. For XML and ASN.1, reject oversized or deeply nested documents at the boundary with a size limit, so the recursion bugs never get a deep input.
Why it matters
A point release with 10 fixes across unrelated packages is the normal rhythm for Go. The temptation is to patch on the next quarterly cycle. The better move is to rebuild now and let the call graph decide the order for anything you cannot rebuild today.
Static linking cuts both ways. There is no shared library to patch, which keeps behavior predictable. But it also means every binary needs a rebuild, and the ones you forgot about are the ones that stay vulnerable.
Reachability analysis answers the practical question for each of those binaries: does my code call the affected function. Safeguard does reachability analysis for exactly this reason, and govulncheck gives you a free first pass for Go specifically.
Try it yourself
Run govulncheck ./... on one of your Go services before upgrading, then again after. Note which findings disappear with the toolchain bump and which come from x/ modules in go.mod.
Click through it at your own pace, or open it full screen.
For a quick look at the Go modules in a project, the free scan runs in your browser with no login, and the file never leaves your machine.
Quick check
Why does patching the Go installation on a server not fix existing services?
Go binaries statically include the standard library they were built with. You have to rebuild with the fixed toolchain and redeploy.
What does govulncheck add over a plain version match?
It checks whether your code has a call path to the vulnerable symbol, so it separates exposed from merely present.
Which two fixes involve the module checksum infrastructure?
CVE-2026-56865 in x/mod/sumdb/tlog and CVE-2026-56864 in x/mod/sumdb.
