AZL-113423: CVE-2026-97039 affecting package golang 1.26.11-1
Building a malicious package that uses "#cgo pkg-config:" directives could load untrusted pkg-config ".pc" files or inject unvalidated compiler and linker flags. The pkg-config flag allowlist previously permitted "--with-path=" and "--personality=", allowed "--define-variable=" values beginning with "=" or "$" (which can rewrite paths in system ".pc" files into sysroot-prefixed "-L=" or "-L$SYSROOT" linker search paths), and allowed package arguments ending in ".pc" or containing path separators or "..", which caused pkg-config to load local ".pc" files directly from the package directory. In addition, flags returned by "pkg-config --cflags" in cgoCPPFLAGS were not checked when determining whether internal linking is safe. The go command now disallows "--with-path=", "--personality=", leading "=" or "$" characters in "--define-variable=" values, and local ".pc" paths in "#cgo pkg-config:" directives, and inspects cgoCPPFLAGS when checking internal linking compatibility.
Affected Software
Event History
Frequently Asked Questions
Who is most exposed to this issue?
Build environments that compile untrusted or third-party Go packages using cgo are the relevant exposure point. Exploitation depends on a malicious package containing #cgo pkg-config directives.
What does an attacker need to control?
An attacker needs to supply a package that is built and that uses crafted #cgo pkg-config arguments. The vulnerable behavior can involve local .pc files, pkg-config path or personality options, define-variable values beginning with = or $, or compiler and linker flags returned by pkg-config.
How can I identify potentially risky source before building it?
Review #cgo pkg-config directives for --with-path=, --personality=, --define-variable= values beginning with = or $, and package arguments that end in .pc or contain path separators or .. . Also treat pkg-config-provided CFLAGS and CPPFLAGS as security-relevant build input.