Go’s checksum database meets its trust assumptions

Go’s module security story has long rested on a carefully drawn boundary: a GOPROXY may be untrusted for content, but the checksum database and its transparency log are supposed to make substitution detectable. That boundary took a coordinated hit this week. Official releases of golang.org/x/mod v0.40.0, Go 1.26.6, Go 1.25.13, and go1.27rc3 all ship the same pair of fixes for sumdb verification failures that let a malicious proxy, alone or paired with a malicious GOSUMDB, persist attacker-controlled modules into a client’s local cache without the transparency log catching them.

The Go Security team’s announcements on golang-nuts and golang-dev, later mirrored to oss-security by Alan Coopersmith, describe two related failures rather than a single bug. CVE-2026-56865 sits in x/mod/sumdb/tlog. A malicious GOPROXY was previously capable of forging up to two sumdb tiles that allowed a requested module to bypass the GOSUMDB check. Once those tiles were accepted, attacker-controlled module content could land in the local module cache and would not be exposed by evaluating the transparency log. The fix is blunt in wording and narrow in scope: all tiles are now correctly verified against their parents. Filippo Valsorda of Geomys is credited with the report.

CVE-2026-56864 sits one layer up, in x/mod/sumdb Lookup handling. A malicious GOSUMDB could serve arbitrary module content that was not contained in the transparency log at all. When that service coordinated with a malicious GOPROXY, the client could be handed bad modules that again could not be detected by log evaluation. The remedy is to ignore unrelated, unauthenticated hashes in Lookup. The reporter is credited as mundur. Both advisories give the same post-incident check: remove go.sum, go.work.sum, and vendor, then run go mod tidy, so that sums are rebuilt against a corrected verifier.

Taken together, the two issues form one story about incomplete verification rather than a collapse of the log design itself. Sumdb’s tile tree is meant to let clients fetch compact proofs and check each piece against a parent hash up to a signed tree head. If a client accepts a tile that is not properly bound to its parent, the proof chain is only as strong as the honesty of whoever served the tile. If Lookup also accepts hashes that were never authenticated as part of that chain, the client’s notion of what the log contains drifts from what the log actually committed to. In the first bug, a hostile proxy could manufacture a short, plausible fragment of the tile tree. In the second, a hostile checksum service could answer with module hashes that the log never recorded. Either way, the client’s cache became a durable store of content the transparency mechanism was supposed to make non-repudiable and non-substitutable.

That is why the releases arrived as a set. x/mod is the library many tools and older toolchains lean on for sumdb client logic; the point releases and the 1.27 release candidate carry the same corrections into the go command itself. The security policy framing is routine (ten fixes in the point releases, with encoding/xml recursion depth and other items alongside), but the sumdb pair is the one that reaches the ecosystem’s default trust path. Default GOPROXY and GOSUMDB values point at infrastructure most developers never configure. The model’s promise has been that even a compromised or malicious mirror cannot silently rewrite module bits, because the client will cross-check against the log. These bugs meant that promise did not hold for the tile and Lookup paths that real downloads exercise.

The sharper question the incident leaves is not whether tiles should be checked against parents (they should, and now are) but how much of everyday safety still hinges on the operator of the proxy and the sumdb endpoint behaving within the roles the protocol assigns them. Go’s design deliberately separates distribution from notarization: proxies cache and serve; the checksum database attests. That separation is only as good as the client’s insistence on a full proof. A forgeable tile or an unauthenticated Lookup response collapses the separation back into a single trust decision about whoever answered the HTTP request. Enterprises that run internal GOPROXY and GOSUMDB pairs, or that point build fleets at third-party mirrors for availability or policy reasons, inherit the same requirement. Correct tile verification is not an optimization; it is the difference between a transparency log and a decorative checksum file.

Community reaction on the announcement threads has been largely absorptive rather than argumentative: the advisories are written as operational facts, with credits, CVE identifiers, and a concrete remediation recipe. The deeper disagreement, where it surfaces in broader supply-chain discussion, is familiar. One side treats the episode as validation of the architecture. Transparency logs and signed tree heads worked as intended once the client actually verified the structure; the failures were implementation gaps in tile parent checks and hash authentication, reported through the project’s security process and shipped across supported releases in lockstep. On that view, the right response is to upgrade x/mod and the toolchain, re-tidy modules, and keep the default sumdb enabled.

The other side reads the same facts as evidence that the ecosystem still underestimates how often clients depend on the friendliness of mirrors. If forging two tiles or injecting unauthenticated Lookup hashes was enough to bypass detection, then “evaluate the transparency log” was not, in practice, the complete client policy many documents implied. Build systems that disable sumdb for air-gapped or vendor-heavy workflows, or that pin to private checksum services with weaker operational review, are not protected by upstream’s tree head. The incident does not prove those deployments wrong, but it does underline that their safety properties are local policy choices, not consequences of the public log.

Technically, the residual surface is clearer than it was a week ago. Parent-linked tile verification closes the forgery path described in CVE-2026-56865. Ignoring unrelated unauthenticated hashes closes the Lookup path in CVE-2026-56864. Neither fix changes the trust anchors, the signed tree head model, or the default public endpoints. Neither claims to address a malicious sumdb operator who signs a bad tree head; that remains a key and governance problem outside these CVEs. What is resolved is the client’s willingness to accept structural nonsense or stray hashes as if they were log evidence.

What remains open is operational and cultural. How many module caches already hold content admitted under the old verifier, and how thoroughly projects will run the suggested tidy cycle, is unknowable from the announcements alone. Whether internal proxy operators will audit their own tile serving and Lookup responses with the same seriousness as the public sumdb is a deployment question, not a language one. And whether the next generation of Go supply-chain hardening leans into stronger client-side proof requirements, or into reducing reliance on remote sumdb lookups in favor of more vendoring and reproducible builds, is a debate these fixes inform but do not settle. For now, the toolchain’s answer is narrow and concrete: verify every tile against its parent, ignore hashes the log did not authenticate, and treat anything admitted before that bar as suspect until rebuilt.