CVE-2026-56865
Executive Summary
CVE-2026-56865 is an improper-verification-of-cryptographic-signature flaw (CWE-347) in the Go module checksum database (GOSUMDB) verification flow. A malicious GOPROXY (Go module proxy) can forge up to two sumdb tiles, allowing attacker-controlled module content to bypass the GOSUMDB check and be persisted to a developer's or CI build agent's local Go module cache. Any environment that resolves Go modules through an untrusted, look-alike, or compromised proxy is affected; successful exploitation results in malicious code entering the build chain, with CVSS 8.4 (High confidentiality/integrity/availability impact) and no user interaction or privileges required from the local perspective.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
Technical Analysis
The Go toolchain verifies downloaded modules against a cryptographic transparency log known as the checksum database (GOSUMDB). When a module is fetched, the toolchain also requests the corresponding records — "tiles" — from the log and verifies each tile's hash chain against its parent tiles up to a signed tree head. This prevents a malicious module proxy from substituting arbitrary module content, because the computed module hash must match the record published in the transparency log.
The flaw documented for CVE-2026-56865 is in this verification step: the client previously accepted certain tiles without correctly verifying them against their parents. Because the parent-linkage check was incomplete, a malicious GOPROXY could forge up to two tiles to fabricate a checksum record for a requested module. From the client's perspective, the forged record appeared consistent with the transparency log, so the GOSUMDB check passed and the attacker-controlled module content was written to the local Go module cache. The attack is therefore invisible to anyone evaluating the transparency log itself — the record the client was shown simply never existed in the authoritative log.
The NVD description does not disclose the exact affected Go toolchain version, the specific tile-handling function, or the precise code path. The technical detail available is limited to the mechanism described above: tile authenticity was not fully enforced, and the correction ensures "all tiles are now correctly verified against their parents." The documentation of the affected artifacts — go.sum, go.work.sum, and the vendor/ directory — confirms the compromise vector: these files represent the cached integrity state of a project's dependency set and must be reset to re-validate dependencies against the authoritative log.
From a vulnerability-class perspective, this is a signature-verification bypass in a Merkle-tree-based transparency log client. The attack surface is the Go module resolution pipeline: a developer or CI agent configured with a custom or private GOPROXY (e.g., a third-party mirror, an internal caching proxy, or a proxy endpoint controlled by an attacker) fetches both module archives and sumdb tiles from that proxy. Because the proxy controls the tile data delivered to the client, an incomplete parent-verification check converts the proxy from a content-delivery service into an integrity-breaking component. The local attack vector in the CVSS vector (AV:L) reflects that the compromise is realized on the local build host where the module cache is persisted and the malicious content is subsequently consumed.
Exploitation Scenarios
No public PoC is available; the attack chain below is inferred from the NVD description, the vulnerability class (CWE-347), and the documented Go module resolution behavior.
Reconnaissance / target identification — An attacker must control a GOPROXY that the victim uses. This can be achieved by (a) operating a publicly reachable, look-alike Go module proxy and inducing adoption through typosquatted documentation or open-source configuration samples, (b) compromising an existing private/corporate module proxy, or (c) causing a victim's environment to switch to a malicious proxy through configuration injection into GOPROXY/GOFLAGS environment variables. Developers and CI systems using non-default proxies are the primary target population.
Trigger of the flaw — When the victim's toolchain runs a module-resolving command (e.g.,
go build,go get, orgo mod tidy), the client contacts the configured GOPROXY for the module archive and contacts the checksum database for the corresponding sumdb tiles. The malicious proxy answers these tile requests with forged tile data — up to two tiles per the description — that contain a checksum matching the attacker-controlled module content rather than the authoritative log.Payload / execution at the vulnerability-class level — Because the tile's linkage to its parent tiles is not verified correctly, the client accepts the forged record as authentic, and the GOSUMDB check passes. The attacker-controlled module content is then persisted to the local Go module cache and is subsequently compiled or executed in the build/test lifecycle of the project. The precise payload mechanism (e.g., code executed during module initialization or code linked into the resulting binary) is not specified in the available data; the execution is a direct consequence of the cached module content being consumed by the build.
Post-exploitation — The malicious code runs with the privileges of the developer or CI build agent. Likely outcomes include theft of signing keys and CI secrets, modification of build outputs, backdooring of release artifacts, and lateral movement from build infrastructure into production environments. Because the forged record appeared consistent with the transparency log, retrospective analysis of the log itself will not reveal the compromise — detection must rely on host-level artifacts (go.sum, go.work.sum, vendor/ inconsistency, module cache contents) rather than log auditing.
Impact Assessment
The business impact is a supply-chain integrity compromise of the Go software build pipeline. The CVSS vector (AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) indicates that exploitation requires no privileges and no user interaction, and the scope remains unchanged — but the confidentiality, integrity, and availability impacts on the local build host are all High. Real-world impact translates to High integrity loss (malicious source accepted into builds), High confidentiality loss (secrets and source code accessible to the injected module), and High availability loss (build breakage or compromised artifacts that must be recalled).
Affected systems include all developer workstations, build servers, and CI/CD pipelines that fetch Go modules through a GOPROXY and rely on GOSUMDB verification — a population that includes any organization using Go with a private module proxy or mirror. The blast radius extends beyond the build host because compromised release artifacts are distributed to customers and internal systems, making the attack a classic software supply-chain risk. The EPSS score is 0.00123 (low current exploitation probability) and the CVE is not present on the CISA KEV list, indicating no confirmed in-the-wild exploitation to date; however, the difficulty of detecting this class of attack after the fact warrants treating the risk as elevated despite the low EPSS percentile.
Detection Guidance
The following detection content focuses on the observable side effects of the CVE: the documented remediation sequence (rm -r go.sum go.work.sum vendor/ && go mod tidy), anomalous Go toolchain behavior, and suspicious module-proxy network exchanges. These rules are intended as detection aids; given the absence of a public PoC, they target the attack's artifact-level footprint rather than specific exploit code.
Sigma Rule
title: Go Module Cache Integrity Reset and Re-sync
id: a38f5c9e-7d2b-4a10-9e6c-1b2f0d4c8a71
status: experimental
description: |
Detects the documented remediation sequence for CVE-2026-56865 on a host:
removal of go.sum, go.work.sum, and vendor/ followed by 'go mod tidy'.
Adversaries may trigger the same sequence to re-resolve dependencies through
a malicious GOPROXY, and legitimate users may execute it after a suspected
module-cache poisoning event; both cases warrant investigation.
logsource:
category: process_creation
product: linux
detection:
selection_rm:
Image|endswith:
- /rm
- /unlink
CommandLine|contains|all:
- 'go.sum'
- 'go.work.sum'
- 'vendor'
selection_go:
Image|endswith:
- /go
CommandLine|contains: 'mod tidy'
condition: selection_rm and selection_go
timeframe: 1m
fields:
- User
- ParentImage
- CommandLine
falsepositives:
- Legitimate dependency hygiene / cache cleanup procedures performed by developers
level: medium
tags:
- attack.t1195
- attack.supply_chain
- cve.2026.56865
- cwe.347
YARA Rule
rule CVE_2026_56865_Go_Module_Archive_Executable
{
meta:
author = "ValtersIT SOC"
description = "Detects Go module archives containing embedded executable or shared-object payloads, consistent with attacker-controlled module content served by a malicious GOPROXY (CVE-2026-56865)."
cve = "CVE-2026-56865"
cwe = "CWE-347"
date = "2026-02-19"
severity = "high"
strings:
$zip_magic = { 50 4B 03 04 }
$elf = { 7F 45 4C 46 } // ELF header
$pe = { 4D 5A } // MZ header
$go_mod = "module " ascii
$vendor = "vendor/" ascii
$so_suffix = ".so" ascii
$sumdb_tile = "tile" ascii
condition:
$zip_magic at 0
and 2 of ($elf, $pe, $so_suffix)
and any of ($go_mod, $sumdb_tile)
and not $vendor
}
Note: This rule is intentionally conservative and scans extracted module archives or module cache content; it flags archive files that combine a Go module marker with an executable payload. The not $vendor condition reduces false positives on legitimate vendored source trees.
Suricata IDS Rule
# CVE-2026-56865 - Detection of HTTP responses from a Go module proxy
# that contain both module metadata and sumdb tile records, indicating
# a single endpoint serving both payload and transparency-log data.
alert http any any -> $HOME_NET any (
msg:"CVE-2026-56865 - Potential malicious Go module proxy serving sumdb tile data";
flow:established,to_client;
http.response_body;
content:"tile/"; nocase;
http.response_body;
content:"go.mod"; nocase; distance:0; within:4096;
http.response_body;
content:"sumdb"; nocase; distance:0; within:8192;
threshold:type both, track by_src, count 3, seconds 60;
metadata:attack_target Server, deployment Perimeter, tag CVE-2026-56865, tag Go-Supply-Chain;
reference:cve,2026-56865;
classtype:attempted-user;
sid:2026568651; rev:1;)
Elastic Detection
sequence by host.name with maxspan=1m
[ file where event.action in ("delete", "unlink") and
file.name in ("go.sum", "go.work.sum") ]
[ process where process.name == "go" and
process.args == "tidy" and
process.parent.name in ("sh", "bash", "zsh", "cmd.exe", "powershell.exe") ]
Additional standalone EQL for unusual module-cache churn:
process where process.name == "go"
and process.args == "mod"
and process.args == "tidy"
and process.command_line in ("*GOPROXY=*", "*GOFLAGS=*")
Splunk SPL Query
index=* sourcetype="WinEventLog:Security" OR sourcetype="linux_audit" OR sourcetype="ProcessRollup2*"
| where (ProcessName LIKE "%\\rm%" AND CommandLine LIKE "%go.sum%")
OR (ProcessName LIKE "%\\go%" AND CommandLine LIKE "%mod tidy%")
OR (ProcessName LIKE "%/go%" AND CommandLine LIKE "%mod tidy%")
| stats count by host, user, ProcessName, CommandLine, ParentProcessName, _time
| sort - _time
Complementary network-side query for suspicious proxy traffic:
index=network sourcetype=stream:http
| search http_content="*tile/*" http_content="*go.mod*"
| stats count by src_ip, dest_ip, dest_host, http_method, http_uri
| sort - count
Wazuh OSSEC Rule
<group name="go,supply_chain,">
<!-- Wazuh cluster / syscheck rule referencing deletion of Go integrity markers -->
<rule id="100568" level="12">
<if_sid>550</if_sid>
<field name="file">go.sum|go.work.sum</field>
<description>CVE-2026-56865: Go checksum/vendor integrity files deleted. Possible response to a poisoned Go module cache.</description>
<options>no_full_log</options>
<group>pci_dss_11.5,gdpr_IV_35.7.d,</group>
</rule>
<!-- auditd process-execution rule for the remediation / re-sync command -->
<rule id="100569" level="10">
<if_sid>5160</if_sid>
<match>go mod tidy|rm -r go.sum</match>
<description>CVE-2026-56865: Go dependency re-sync command observed. Verify the GOPROXY configuration is trusted.</description>
<group>attack.t1195,</group>
</rule>
</group>
Mitigation & Patch Guidance
Patch confidence: 0/4 — UNPATCHED. No vendor advisory, patched release, or commit reference is available from any tracked source, even though the NVD description indicates the verification logic was corrected ("All tiles are now correctly verified against their parents"). Treat the Go toolchain as vulnerable until an official patched release is identified and confirmed.
Immediate mitigations — If there is any indication that a non-default GOPROXY was used, or if module resolution is suspected of having been tampered with, execute the documented reset procedure verbatim:
rm -r go.sum go.work.sum vendor/ && go mod tidyThis forces the toolchain to re-resolve and re-verify all dependencies against the authoritative checksum database. Additionally, clear the compromised content from the local Go module cache and re-run the resolution from a clean directory so that attacker-controlled cached archives are not re-used during re-resolution.Patch / upgrade steps — Monitor the official Go project release channels and the NVD record for an advisory that identifies the patched Go toolchain version. Because no patched version is currently identified, do not assume that any installed Go version is immune. Once an advisory is published, upgrade the toolchain on all developer workstations, CI/CD agents, and container build images to the fixed release, then repeat the
rm -r go.sum go.work.sum vendor/ && go mod tidyreset.Long-term hardening — Restrict GOPROXY to the official default proxy or to a private proxy whose integrity is controlled by the organization; enforce TLS-only module fetching. Verify that GOSUMDB is enabled and points to the official checksum database in all build environments. Pin and vendor dependencies with reviewed checksums where feasible, and treat any re-sync of go.sum/go.work.sum as a security-relevant event requiring review. In CI/CD pipelines, add software-composition-analysis scanning of newly introduced modules, run builds in isolated/ephemeral agents with least privilege, and restrict egress from build agents to an explicit allowlist of module-proxy and checksum-database endpoints. Finally, periodically audit the module cache and go.sum files for modules that were never approved by the engineering organization.
References
- NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-56865
- MITRE CVE Record: https://www.cve.org/CVERecord?id=CVE-2026-56865
- CWE-347 (Improper Verification of Cryptographic Signature): https://cwe.mitre.org/data/definitions/347.html
- Go Modules Reference (GOPROXY / GOSUMDB / checksum database mechanics): https://go.dev/ref/mod
- FIRST EPSS Score for CVE-2026-56865: https://first.org/epss/
No vendor advisory, researcher blog post, or threat-actor campaign report is currently available. CISA KEV status: NO — no confirmed exploitation in the wild has been documented; the EPSS score (0.00123) reflects a low observed exploitation signal, but the supply-chain impact of this vulnerability warrants proactive detection and mitigation.
What is this? Security researchers use these exact search queries on Shodan.io (a search engine for internet-connected devices) to find vulnerable systems globally. You can copy these dorks to see if your organization's IP space is exposed.
💣 PoC CODE AVAILABLE
Exploit code for this CVE is tracked in our database.
Access poc_code via API Pro.