Package
cargobump
Component
chainguard.dev/apko
Latest update
8.3
CVSS V3
Build, ship, and run secure software with minimal, hardened container images — rebuilt from source daily and guarded under our industry-leading remediation SLA.
Start for freeStatus
Justification
Impact
CVE-2026-54174 / GHSA-fpg8-7664-jc5q describes incomplete package integrity verification in apko/melange that allows an attacker to substitute the data section of a package. This vulnerability is not present in the shipped cargobump artifact.
cargobump depends on chainguard.dev/apko but imports only a single package, apko/pkg/log, which it uses solely for log-level configuration. The apko package-integrity-verification code that contains the vulnerable behavior lives in separate apko packages that cargobump never imports.
Evidence: symbol analysis of the shipped binary (go tool nm) shows the only apko symbols linked are from apko/pkg/log (log.CharmLogLevel.Set/String/Type, log.Writer). No apko package-verification symbols are present; Go's linker eliminates the unused code, so the vulnerable functions are not compiled into the artifact.
Scanner note: the upstream Go vulnerability record for this CVE is scoped to the entire chainguard.dev/apko module with no symbol-level data. Consequently govulncheck (binary mode) reports the module as affected and lists the reachable apko/pkg/log symbols as "vulnerable symbols." Those are logging helpers, not the vulnerable package-verification functions; the match is a byproduct of module-scoped advisory metadata, not evidence the vulnerable code is reachable.
apko is pinned to v0.14.5 via a go.mod replace directive; the upstream fix is in apko 1.2.9. Because the vulnerable code is not included in the cargobump build, this detection is a false positive (vulnerable-code-not-included-in-package; VEX: vulnerable_code_not_present).
Status