Improper verification in Go toolchain cmd/go and golang.org/x/mod/sumdb can hide malicious modules

A malicious GOSUMDB was capable of serving arbitrary module content not contained within the transparency log. This attack allows for a coordinating GOPROXY and GOSUMDB to serve a client malicious module content that cannot be detected by evaluating the transparency log. In order to determine if you have been affected: rm -r go.sum go.work.sum vendor/ && go mod tidy

• Go toolchain cmd/go: affected from version 0 through versions less than 1.25.13.
• Go toolchain cmd/go: affected from 1.26.0-0 through versions less than 1.26.6.
• Go toolchain cmd/go: affected from 1.27.0-0 through versions less than 1.27.0-rc.3.
• golang.org/x/mod/sumdb: affected in versions less than 0.40.0; the record identifies the Client.Lookup symbol.

These are the branch-specific boundaries supported by the record. The status of an unlisted parallel branch or version should not be inferred solely because another branch has a fix.

The affected path is golang.org/x/mod/sumdb, including Client.Lookup, as used by cmd/go. The weakness is classified as CWE-347, improper verification of cryptographic signatures or evidence. A malicious GOSUMDB can serve arbitrary module content that is not contained in the transparency log; when coordinated with a GOPROXY, it can provide malicious module content to a client without that content being detected by evaluating the log. The available material does not specify the exact protocol message or parser-level condition that allows unrelated, unauthenticated hashes to bypass validation. Exposure should therefore be checked in both Go toolchains that embed the component and environments that use golang.org/x/mod/sumdb directly.

The described attack is network-delivered through a client obtaining module data from a coordinating GOPROXY and GOSUMDB. The normalized record characterizes the attack as low complexity, requiring no privileges and no user interaction. Coordination between the two services is a material condition of the described scenario, but the available evidence does not define the deployment or control requirements in more detail. The supplied record does not identify a public exploit or known exploitation, and it names no campaign, victim, or specific indicator of compromise.

The primary technical outcome is that a client can receive arbitrary module content outside the set recorded by the transparency log, so log-based dependency verification is no longer reliable. Organisational consequences may include reduced confidence in dependency provenance and increased risk of untrusted content entering builds or artifacts. The record's attack metadata describes no required privileges and no user interaction, but it does not establish payload execution, privilege escalation, data loss, or service disruption in a particular environment. The described impact therefore remains a supply-chain verification risk rather than evidence of a completed compromise.

The flaw weakens dependency acquisition trust because a client may receive attacker-controlled module content even though that content is not recorded in the transparency log. If consumed by a build or release workflow, the content could undermine confidence in dependency provenance and artifact trust. Whether it is compiled, executed, or propagated into an artifact depends on how the environment uses the module and is not established by this record. No specific victim, payload, breach, or data theft is identified.

1. Upgrade cmd/go to the fixed release for the branch in use: 1.25.13, 1.26.6, or 1.27.0-rc.3. These are the specific supported fixed points and should not be generalized into an open-ended range for every later version.
2. If the application uses the module directly, upgrade golang.org/x/mod/sumdb to v0.40.0.
3. For code or toolchains that vendor x/mod, refresh the vendored copy through the corresponding Go toolchain fix rather than changing an unrelated direct dependency.
4. After updating, regenerate and review module metadata with rm -r go.sum go.work.sum vendor/ && go mod tidy in a recoverable checkout. Preserve the files and directory before running because the command removes them.
5. If the check shows unexpected dependency or checksum changes, isolate the result and compare it with a trusted baseline or module source before continuing builds.

1. Inventory the installed Go toolchain versions, with particular attention to the affected cmd/go branches.
2. Inspect dependency graphs, module caches, and vendor trees for golang.org/x/mod/sumdb or use of Client.Lookup.
3. In a clean or recoverable checkout, run the exact Go-provided check: rm -r go.sum go.work.sum vendor/ && go mod tidy. This removes the listed files and directory, so preserve a copy before running it.
4. Compare regenerated module and checksum changes with a trusted baseline, especially when the dependency graph changes unexpectedly.
5. The record supplies no named IOC or log event. The absence of a matching log entry does not prove safety; additional monitoring should be treated as a precaution rather than a confirmed detection method.