CVE-2026-97042: 
Golang vulnerability analysis and mitigation

CVE-2026-97042 is an argument injection vulnerability in the Go toolchain affecting cmd/cgo, cmd/compile, and cmd/link components. It allows a malicious Go package or crafted PE object file to pass unsafe library arguments to the external linker by exploiting insufficient validation of library names in //go:cgo_import_dynamic directives and imported DLL names on Windows. Affected versions include all Go toolchain releases before 1.26.11 and 1.27.0-0 through 1.27.4. The vulnerability was published on November 11, 2026, with patches available in Go 1.26.11 and 1.27.4. Feedly estimates the severity as HIGH; a formal CVSS base score has not been published at this time (GitHub Advisory, Feedly).

The root cause is improper input validation (CWE-88, Argument Injection) in multiple Go toolchain components. The compiler validated only the first character of library names in //go:cgo_import_dynamic directives and skipped validation entirely in cgo-generated files. On Windows, cmd/cgo and cmd/link failed to validate imported DLL names extracted from PE object files before emitting -l<name> flags to the external linker, allowing crafted DLL names containing .. path traversal sequences, path separators, :, or leading - or @ characters to reference arbitrary files on disk. Exploitation requires an attacker to supply a malicious Go package or crafted PE object file that is subsequently compiled by a victim's build environment (GitHub Advisory, Go Issue).

Successful exploitation can result in arbitrary file access or code execution during the build process on systems that compile the malicious package. An attacker who can introduce a malicious Go package or PE object file into a build pipeline can leverage path traversal in linker flags to reference and potentially load arbitrary files from disk, escalating to code execution in the build environment. The impact is primarily confined to build systems and CI/CD pipelines that process untrusted Go packages or PE object files, but compromise of such systems can enable lateral movement into broader infrastructure (GitHub Advisory, Feedly).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time. The vulnerability requires an attacker to supply a malicious package or PE object file that is compiled by a target system, limiting opportunistic exploitation. No threat actor attribution has been reported, and the CVE is not listed in the CISA Known Exploited Vulnerabilities catalog. The EPSS score is 0.0, reflecting the current absence of observed exploitation (Feedly, GitHub Advisory).

1. Craft malicious package: Create a Go package containing a //go:cgo_import_dynamic directive with a library name that bypasses the first-character-only validation, embedding path traversal sequences (e.g., ..) or special characters to reference an arbitrary file on disk.
2. Alternatively, craft a malicious PE object: On Windows, construct a PE object file with an imported DLL name containing .., path separators, :, or leading - or @ characters.
3. Distribute the package: Publish the malicious package to a public or private Go module repository, or introduce it as a dependency in a supply chain attack targeting a victim's build environment.
4. Trigger compilation: Induce the victim's build system (e.g., CI/CD pipeline) to compile the malicious package using a vulnerable Go toolchain version (before 1.26.11 or 1.27.4).
5. Linker flag injection: During compilation, cmd/cgo or cmd/link emits the crafted -l<name> flag to the external linker without validation, causing the linker to reference or load an arbitrary file from disk.
6. Achieve code execution: The external linker processes the injected argument, potentially loading attacker-controlled code or files, resulting in arbitrary code execution within the build environment (GitHub Advisory, Go Issue).

• Build Logs: Presence of -l linker flags containing .., path separators (/, \), :, or leading - or @ characters in Go build output or linker invocation logs.
• File System: Unexpected files accessed or loaded from non-standard directories during Go build processes; unusual DLL files referenced from paths outside standard library directories on Windows.
• Process: External linker processes (e.g., gcc, clang, link.exe) spawned with anomalous -l arguments referencing relative or absolute paths outside expected library directories.
• Network: Unexpected outbound connections from build servers following compilation of third-party or newly introduced Go packages.

Upgrade the Go toolchain to version 1.26.11 or 1.27.4 or later, which validate every character of library names in //go:cgo_import_dynamic directives and reject PE imported DLL names containing path separators, .., :, or leading - or @. As a workaround, restrict build environments to trusted Go packages and PE object files, and implement controls limiting access to external linker operations. Review build logs for suspicious library references during compilation. Organizations using CI/CD pipelines should enforce dependency pinning and integrity verification for all Go modules (GitHub Advisory, Go CL).

The vulnerability was announced via the official golang-announce mailing list and tracked in the Go issue tracker. Coverage has appeared on OSS-Sec and security aggregators including VulnDB and OSV. No notable independent researcher commentary or significant social media discussion has been identified beyond standard vulnerability tracking (golang-announce, OSS-Sec).