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

CVE-2026-97039 is a pkg-config argument injection vulnerability in the Go toolchain's cmd/go component that allows a malicious package using #cgo pkg-config: directives to load untrusted .pc files or inject unvalidated compiler and linker flags during the build process. It affects Go toolchain versions prior to 1.26.11 and versions 1.27.0-0 through 1.27.4 (fixed in 1.27.4). The vulnerability was published on November 11, 2026, and is classified as HIGH severity by Feedly's estimate; the EUVD base score is listed as 0.0 pending full NVD scoring (GitHub Advisory, EUVD).

The root cause is insufficient validation of pkg-config flags and arguments processed via #cgo pkg-config: directives in CGo-enabled Go packages (CWE-88: Argument Injection). Specifically, the pkg-config flag allowlist incorrectly permitted --with-path= and --personality= flags, allowed --define-variable= values beginning with = or $ (enabling rewriting of system .pc file paths into sysroot-prefixed -L= or -L$SYSROOT linker search paths), and accepted package arguments ending in .pc or containing path separators or .., causing pkg-config to load local .pc files directly from the attacker-controlled package directory. Additionally, flags returned by pkg-config --cflags in cgoCPPFLAGS were not inspected when determining whether internal linking was safe. The fix, applied in Go change list CL 862152, disallows these dangerous flags and enforces validation of cgoCPPFLAGS (GitHub Advisory, Go Issue).

Successful exploitation allows an attacker who crafts a malicious Go package to inject arbitrary compiler and linker flags and load untrusted pkg-config files during the build process, leading to arbitrary code execution on the machine performing the build. The impact is primarily a supply-chain risk: developers or CI/CD systems that build untrusted or third-party Go packages with CGo enabled are at risk of code execution under the build user's privileges, potentially enabling lateral movement, credential theft, or persistent access to build infrastructure (GitHub Advisory, Feedly).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the disclosure date (Feedly). The EPSS score is 0.0, indicating a very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires an attacker to distribute a malicious Go package that a victim builds with CGo enabled, making it a supply-chain attack vector rather than a direct network attack.

1. Craft a malicious Go package: Create a Go package with CGo enabled that includes a #cgo pkg-config: directive referencing a crafted package name ending in .pc or containing .. path traversal sequences.
2. Embed a malicious .pc file: Place a malicious pkg-config .pc file in the package directory that specifies attacker-controlled compiler flags (e.g., -I, -L paths pointing to attacker-controlled libraries) or linker flags that load a malicious shared library.
3. Inject dangerous flags: Use --define-variable= values beginning with = or $ to rewrite linker search paths, or include --with-path= or --personality= flags to redirect pkg-config's search to attacker-controlled directories.
4. Distribute the package: Publish the malicious package to a public or private Go module registry, or introduce it as a dependency in a supply-chain attack.
5. Trigger victim build: When a victim runs go build on a project that depends on the malicious package with CGo enabled, the injected flags are passed to the C compiler/linker, causing execution of attacker-controlled code during the build process (GitHub Advisory, Go Issue).

• Build Logs: Presence of unexpected --with-path=, --personality=, or --define-variable= flags with leading = or $ characters in CGo build output or verbose go build -v logs.
• File System: Unexpected .pc files in Go package source directories (especially with path traversal components like .. in filenames or referencing local paths); unusual shared libraries or object files created in build directories.
• Process: Unexpected child processes spawned during go build execution (e.g., shells, network utilities like curl or wget) originating from the C compiler or linker invoked by the Go toolchain.
• Network: Outbound network connections from the build host to unknown external IPs initiated during a go build operation.
• Logs: Go build system logs referencing .pc files loaded from package source directories rather than system pkg-config paths (/usr/lib/pkgconfig, /usr/share/pkgconfig).

Upgrade to Go 1.26.11 or later (for the 1.26.x branch) or Go 1.27.4 or later (for the 1.27.x branch), which enforce the corrected pkg-config flag allowlist and cgoCPPFLAGS validation (GitHub Advisory, golang-announce). As a workaround prior to patching, avoid building untrusted or unreviewed third-party Go packages that use CGo, and audit #cgo pkg-config: directives in dependencies. Organizations should also restrict the sources from which packages are fetched in CI/CD pipelines and enforce module verification via GONOSUMCHECK and GOFLAGS controls.

The Go security team announced the fix via the golang-announce mailing list and published the vulnerability details in the Go vulnerability database (golang-announce, Go Vuln DB). The issue was also discussed on the oss-security mailing list shortly after disclosure (oss-sec). Community reaction has been measured given the absence of active exploitation and the supply-chain nature of the attack, which requires victim interaction to trigger.