CVE-2026-56864: 
Golang vulnerability analysis and mitigation

CVE-2026-56864 is a cryptographic signature verification bypass vulnerability in the Go toolchain (cmd/go) and the golang.org/x/mod/sumdb package, classified under CWE-347 (Improper Verification of Cryptographic Signature). A malicious GOSUMDB server can serve arbitrary module content not recorded in the transparency log, and when coordinating with a malicious GOPROXY, can deliver tampered Go modules to clients without detection. Affected versions include cmd/go before 1.25.13, 1.26.x before 1.26.6, and 1.27.0-rc.x before 1.27.0-rc.3, as well as golang.org/x/mod/sumdb before 0.40.0. The vulnerability was published on August 13, 2026, and is estimated HIGH severity (golang-announce, OSV).

The root cause is improper verification of cryptographic signatures (CWE-347): the Go module client failed to adequately validate that module content served by a GOSUMDB was actually recorded in the public transparency log. An attacker controlling both a GOPROXY and a GOSUMDB can serve a client a malicious module zip whose hash is not present in the transparency log, bypassing the checksum database's integrity guarantees. This attack requires the attacker to be in a position to act as (or compromise) both the proxy and the sum database — for example, via a private or enterprise-controlled GOPROXY/GOSUMDB configuration. Relevant code changes are tracked in Go CLs 815000 and 815020, and the issue is documented at go.dev/issue/80745 (golang-announce, OSV).

Successful exploitation allows an attacker to silently inject arbitrary, potentially malicious Go module content into a developer's or CI/CD build environment without triggering transparency log verification failures. This can lead to supply chain compromise, enabling code execution within built applications, credential theft, backdoor installation, or lateral movement across systems that consume the affected modules. The integrity of the Go module ecosystem's trust model is undermined, as the transparency log — the primary defense against module tampering — is rendered ineffective in this attack scenario (golang-announce, OSV).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported as of the disclosure date. The attack requires a coordinating malicious GOPROXY and GOSUMDB, limiting opportunistic exploitation; however, organizations using private or custom module proxies and sum databases face elevated risk. The EPSS score is 0.0 and the vulnerability is not listed in the CISA KEV catalog (OSV, oss-sec).

1. Setup malicious infrastructure: Attacker operates or compromises both a GOPROXY server and a GOSUMDB server, or convinces a target to use attacker-controlled values for GOPROXY and GOSUMDB environment variables (e.g., via a compromised enterprise proxy configuration).
2. Prepare malicious module: Craft a modified Go module zip containing malicious code (e.g., a backdoored dependency), ensuring its hash does NOT appear in the public transparency log.
3. Serve tampered module via GOPROXY: When the victim's Go toolchain requests a module, the malicious GOPROXY serves the tampered module zip.
4. Bypass transparency log check via GOSUMDB: The malicious GOSUMDB responds to the client's hash lookup with a fabricated or manipulated response that passes the client's (flawed) verification, preventing detection of the discrepancy.
5. Module integrated into build: The victim's go mod tidy or go get command accepts the malicious module, which is incorporated into the build and subsequently executed in production environments.
6. Detect potential compromise: Run rm -r go.sum go.work.sum vendor/ && go mod tidy against a trusted GOPROXY/GOSUMDB to check for unexpected module content changes (golang-announce, OSV).

• File System: Unexpected changes in go.sum or go.work.sum hashes after re-running go mod tidy against a trusted proxy; presence of unfamiliar or modified module content in the module cache ($GOPATH/pkg/mod).
• Environment/Configuration: GOPROXY or GOSUMDB environment variables set to non-default or unrecognized endpoints in build scripts, CI/CD pipelines, or developer workstations.
• Network: Outbound connections from build systems to unexpected GOPROXY or GOSUMDB hostnames; DNS queries for unfamiliar module proxy or sum database domains.
• Logs: Build logs showing module downloads from non-standard proxy URLs; discrepancies between module hashes recorded locally and those in the public sum database when cross-checked manually (golang-announce).

Upgrade to fixed versions: cmd/go 1.25.13, 1.26.6, or 1.27.0-rc.3 (or later), and golang.org/x/mod/sumdb 0.40.0 or later. To check for prior compromise, run rm -r go.sum go.work.sum vendor/ && go mod tidy against a trusted GOPROXY and GOSUMDB. Organizations should audit their GOPROXY and GOSUMDB environment variable configurations to ensure they point only to trusted, official endpoints (e.g., https://proxy.golang.org and sum.golang.org) (golang-announce, OSV).

The Go security team disclosed the vulnerability via the golang-announce mailing list and the OSS-Security list, following standard coordinated disclosure practices. The issue was also tracked on the OSV vulnerability database and Tenable's plugin pipeline. Community discussion has been limited, reflecting the relatively narrow exploitation preconditions required (golang-announce, oss-sec).