Transparency log tile verification bypass in Go toolchain cmd/go and golang.org/x/mod

A malicious GOPROXY was previously capable of forging up to two sumdb tiles that allow for a requested module to bypass the GOSUMDB check and persist attacker-controlled module content to a local Go module cache. This attack allows for a malicious GOPROXY to serve malicious module content that cannot be detected by evaluating the transparency log. All tiles are now correctly verified against their parents. 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 before 1.25.13; from 1.26.0-0 before 1.26.6; and from 1.27.0-0 before 1.27.0-rc.3.
• golang.org/x/mod/sumdb/tlog: affected before v0.40.0.
• The Go report identifies the affected internal symbol as tileHashReader.ReadHashes.
• The record sets the default status to unaffected outside the listed ranges, but does not independently enumerate every parallel branch. Do not infer the status of an unlisted branch solely from a fix in another branch.

The affected implementation is golang.org/x/mod/sumdb/tlog, including the internal symbol tileHashReader.ReadHashes, together with its integration path in cmd/go. When a client retrieves modules through GOPROXY, attacker-controlled responses could forge up to two sumdb tiles. Before the fix, tiles were not consistently verified against their parent tiles, which could allow a requested module to bypass the GOSUMDB check and persist in the local Go module cache. This is an improper verification of cryptographic signatures issue classified as CWE-347. The precondition is a client performing module resolution through a malicious or compromised GOPROXY; the supplied assessment characterizes reachability as local rather than direct network access to an arbitrary service. Public evidence does not further describe the exact forged-tile construction or cache artifact layout, so those details should not be assumed.

• Reachability: The supplied assessment characterizes the attack as local; exposure depends on a client resolving modules through a malicious or compromised GOPROXY.
• Authentication and interaction: The assessment records no privileges required and no user interaction required for exploitation of the affected path.
• Complexity: The assessment characterizes the attack complexity as low once the client uses the affected proxy path.
• Exploitation status: The record does not record a public exploit and does not name a specific exploited campaign. This describes the available evidence and does not prove that exploitation never occurred in any environment.

• The flaw weakens the integrity verification performed through GOSUMDB and the transparency log.
• Under the affected conditions, malicious module content could remain in a local cache and be consumed by builds or other tools as if it were a valid dependency.
• Possible technical outcomes include altered compiled code, execution of untrusted code in a developer or build-process context, and effects on the confidentiality, integrity, or availability of downstream systems.
• The primary affected scope is the client and build environment using the vulnerable module-fetch path. The available evidence does not establish privilege escalation, direct access to an arbitrary service, or a specific compromise.

• Attacker-controlled module content could be placed in a local Go module cache while transparency-log evaluation fails to reveal the substitution.
• If that content is later selected by builds, tests, packaging, or developer tooling, it could undermine software integrity and create a supply-chain compromise path.
• Possible downstream consequences include altered build outputs, execution of untrusted code, exposure of secrets available to build processes, or service disruption. The record does not confirm any of these consequences in a specific environment.
• The main organisational concern is trust in dependency retrieval and build reproducibility, especially on CI runners and developer machines that share GOPROXY settings.

1. Upgrade Go toolchain cmd/go on each affected branch to the exact repaired release: 1.25.13 for the 1.25 line, 1.26.6 for the 1.26 line, and 1.27.0-rc.3 for the listed 1.27 pre-release line. Do not treat a fix for one branch as evidence about an unlisted branch.
2. If golang.org/x/mod is used directly, update golang.org/x/mod/sumdb/tlog to v0.40.0.
3. For workspaces that may have been affected, apply the Go-provided check and dependency regeneration command:

rm -r go.sum go.work.sum vendor/ && go mod tidy

1. Review dependency changes after this operation before returning them to build or release pipelines. If unexpected content is found, treat the related cache and derived artifacts as untrusted until they are re-verified.
2. The available sources do not provide additional cache-forensics guidance or specific IOCs; unsupported detection criteria should not be invented.

1. Inventory Go toolchain versions on developer workstations, build agents, and CI runners, and check the golang.org/x/mod dependency and any related vendored copies.
2. Review GOPROXY configuration and proxy access logs to determine whether systems used a proxy outside organisational control or one that may have been compromised. This is contextual review, not a confirmed IOC.
3. For workspaces that may have been exposed, run the Go-provided check:

rm -r go.sum go.work.sum vendor/ && go mod tidy

1. Review dependency changes after regenerating the module state and investigate unexpected modules or content in the cache, lockfiles, and build artifacts.
2. No specific log signature or IOC is provided by the available evidence. The absence of suspicious logs does not prove that a cache is safe.