CVE-2026-97040: 
Golang Analyse et atténuation de la vulnérabilité

CVE-2026-97040 is a linker flag injection vulnerability in the Go toolchain (cmd/go and cmd/link) that allows a crafted .syso file to bypass cgo flag validation and inject arbitrary linker flags during the build process. The vulnerability was published on November 11, 2026, and affects all Go toolchain versions before 1.26.11 and versions 1.27.0–1.27.3 (before 1.27.4). It is classified as HIGH severity by Feedly's estimate; a formal CVSS score has not been published at this time. Patches are available in Go 1.26.11+ and 1.27.4+ (GitHub Advisory, Go Vuln DB).

The root cause is insufficient validation of .syso files during the Go linking process (related to CWE-94, Code Injection). When loading .syso entries from a package archive, cmd/link only checked for recognized host object headers (ELF, Mach-O, PE, XCOFF) before falling through to Go object parsing. A crafted .syso file beginning with a go object header was incorrectly parsed as a Go compiler object, allowing untrusted cgo metadata directives — such as cgo_ldflag or cgo_dynamic_linker — to be passed directly to the external linker without validation. Two additional weaknesses compounded the issue: .syso filenames longer than 16 bytes lost their .syso extension when truncated in archive headers (causing misidentification), and unrecognized .syso formats could force external linking even in pure-Go builds. The fix causes the linker to reject .syso files that are not recognized host object formats, and cmd/go and cmd/pack now preserve the .syso suffix when truncating long archive member names (GitHub Advisory, Go Issue).

An attacker who can introduce a malicious .syso file into a package — for example, via a supply chain compromise, a malicious dependency, or a contributed package — can inject arbitrary linker flags during the build process of any project that includes the affected package. This can lead to build-time code injection, manipulation of the resulting binary (e.g., embedding backdoors or altering dynamic linker paths), and potentially full compromise of software produced by the affected build pipeline. Pure-Go builds are also affected, as unrecognized .syso formats can force external linking, expanding the attack surface (GitHub Advisory, Feedly).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires the ability to introduce a crafted .syso file into a target's build pipeline, making it primarily a supply chain attack vector rather than a remotely exploitable network vulnerability (GitHub Advisory, Go Vuln DB).

1. Craft a malicious .syso file: Create a file beginning with a go object header (mimicking a Go compiler object) that embeds untrusted cgo metadata directives such as cgo_ldflag or cgo_dynamic_linker pointing to attacker-controlled libraries or linker scripts.
2. Introduce the file into a target package: Inject the crafted .syso file into a Go package via a supply chain compromise (e.g., a malicious open-source dependency, a compromised package repository, or a direct contribution to a target project).
3. Optionally use a long filename: Name the .syso file with a filename longer than 16 bytes so that the .syso extension is truncated in archive headers, causing the file to be misidentified and bypassing extension-based checks.
4. Trigger a build: Wait for or cause the victim to build a Go project that includes the malicious package. The Go linker processes the .syso file, parses it as a Go compiler object, and passes the embedded cgo_ldflag or cgo_dynamic_linker directives to the external linker without validation.
5. Achieve code injection: The injected linker flags cause the external linker to link attacker-controlled code or libraries into the final binary, resulting in a backdoored or otherwise compromised executable (GitHub Advisory, Go Issue).

• File System: Presence of unexpected .syso files in Go package directories, especially those with filenames longer than 16 bytes or with a go object magic header instead of standard ELF/Mach-O/PE/XCOFF headers.
• Build Logs: Unusual or unexpected linker flags appearing in build output (e.g., -rpath, -dynamic-linker, or custom library paths not present in the project's source); warnings or errors from the Go linker related to .syso file parsing on unpatched versions.
• Binary Analysis: Compiled Go binaries referencing unexpected dynamic linker paths or linked against unrecognized shared libraries not present in the project's declared dependencies.
• Dependency/Supply Chain: Newly introduced or recently updated Go dependencies containing .syso files, particularly from unverified or recently transferred package maintainers.

Update the Go toolchain to version 1.26.11 or later (for the 1.26.x branch) or 1.27.4 or later (for the 1.27.x branch), which contain the fix that causes the linker to reject .syso files not matching recognized host object formats and preserves .syso suffixes during archive member name truncation. As a complementary measure, implement package validation and integrity checks in your build pipeline to detect tampered or unexpected .syso files before compilation. Use dependency pinning, code signing, and verification for all third-party Go dependencies to reduce supply chain risk (GitHub Advisory, Go CL).

The vulnerability was announced via the official golang-announce mailing list and discussed on the oss-security mailing list shortly after disclosure. Coverage has been picked up by standard vulnerability tracking services including OSV, VulnDB, and Tenable (Nessus detection ID 378564). No notable independent researcher commentary or significant social media discussion has been identified beyond standard aggregator coverage (golang-announce, oss-sec, Tenable).