Go Toolchain EUVD-2026-58514

Exploitation requires two simultaneous conditions: the victim's Go toolchain must be a vulnerable version (cmd/go < 1.25.13, 1.26.x < 1.26.6, or 1.27 pre-rc.3), and the victim must fetch module data through a GOPROXY that coordinates with a malicious GOSUMDB. The default public GOSUMDB (sum.golang.org) would need to be either compromised or replaced via the GONOSUMDB, GONOSUMCHECK, or GOPRIVATE environment variables or go env configuration to redirect verification to an attacker-controlled endpoint. A GOPROXY alone cannot mount this attack without a cooperating malicious GOSUMDB because the hash mismatch would still be locally detectable without the verifier bypass. Exploitation is further limited to the period when a developer actively runs go module fetching commands - passive installations are not affected. Retrospective detection is also prevented because the transparency log bypass leaves no anomalous entry in go.sum.

The official CVSS 7.5 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) is internally inconsistent with the described attack: real-world exploitation requires coordinating both a malicious GOPROXY and a malicious GOSUMDB endpoint simultaneously, which argues for AC:H rather than AC:L; additionally, the primary real-world impact is integrity compromise (silent injection of arbitrary code into the dependency graph) rather than confidentiality loss, so the C:H/I:N impact assignment appears inverted. The EPSS score of 0.12% at the 2nd percentile is consistent with no observed opportunistic exploitation and reflects the high coordination overhead. This vulnerability is not listed in CISA KEV and no POC is publicly known, so mass exploitation is not an immediate threat; however, the supply chain nature means that even a mid-sized municipal IT team in rybnik managing internal Go-based services should treat remediation as urgent because poisoned dependencies may have already been fetched and committed before the patch was available. The most important compensating action is retrospective: any organization that ran go module operations against an untrusted GOSUMDB endpoint during the vulnerability window must re-fetch all checksums after upgrading, as the transparency log bypass leaves no client-side artifact of tampering. The 'JWT Attack' tag present in source metadata does not correspond to any mechanism described in the CVE or its references and appears to be a mis-classification.

An attacker who operates or has compromised both a GOPROXY instance and a GOSUMDB endpoint configures them to cooperate: the proxy serves a Go module containing malicious code, while the GOSUMDB returns a crafted hash that passes the client's local consistency check without being present in the public transparency log. A developer or CI pipeline running 'go mod tidy' or 'go get' against these endpoints silently receives and records the tampered module in go.sum with no warning. No public exploit code has been identified at time of analysis.