Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
8 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Previously, Apko verified the control section hash (.PKGINFO etc.) against the signed APKINDEX, but never verified the data section hash (the actual package files that get installed). An attacker who could compromise a mirror, poison a cache, or MITM a package fetch could substitute arbitrary file contents while the control hash check still passed.
Recommended action: Upgrade to 1.2.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
apko verifies the signature on APKINDEX.tar.gz but never compares individually downloaded .apk packages against the checksum recorded in the signed index. The checksum is parsed and available via ChecksumString(), and the downloaded package control hash is computed, but the two values are never compared in getPackageImpl(). Mismatched packages are silently accepted. An attacker who can substitute download responses (compromised mirror, HTTP repository, poisoned CDN cache) can install arbitrary packages into built images. Fix: No fix available yet. Acknowledgements apko thanks Oleh Konko from 1seal for discovering and reporting this issue.
Recommended action: Upgrade to 1.2.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A crafted .apk could install a TypeSymlink tar entry whose target pointed outside the build root, and a subsequent directory-creation or file-write entry in the same or later archive could traverse that symlink to reach host paths the build user could write to. The root cause was the sanitizePath helper in pkg/apk/fs/rwosfs.go, which rejected only lexical .. traversal and did not resolve or refuse symlinks. Every disk-backed DirFS method that handed its caller-supplied path to a symlink-following stdlib call — ReadFile, WriteFile, Chmod, Chown, Chtimes, MkdirAll, Mkdir, and Mknod — was affected. The reachable primitive from a malicious APK during tar extraction is the MkdirAll / Mkdir / WriteFile chain via apko build-cpio and disk-backed consumers such as melange; the remaining sinks are reachable by direct callers of the pkg/apk/fs package. The in-memory tarfs install path used by apko build, apko publish, and apko build-minirootfs is not affected. Patches Fixed in apko…
Recommended action: Upgrade to 1.2.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
DiscoverKeys in pkg/apk/apk/implementation.go unconditionally type-asserts JWKS keys as rsa.PublicKey without checking the key type. If a repository JWKS endpoint returns a non-RSA key (e.g. EC), the unchecked assertion panics and crashes apko. This affects any workflow that initializes the APK database and fetches repository keys. Affected versions <= 0.30.34. Fix: No fix available yet. Acknowledgements apko thanks Oleh Konko from 1seal for discovering and reporting this issue.
Recommended action: Upgrade to 1.2.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
expandapk.Split drains the first gzip stream of an APK archive via io.Copy(io.Discard, gzi) without explicit bounds. With an attacker-controlled input stream, this can force large gzip inflation work and lead to resource exhaustion (availability impact). The Split function reads the first tar header, then drains the remainder of the gzip stream by reading from the gzip reader directly without any maximum uncompressed byte limit or inflate-ratio cap. A caller that parses attacker-controlled APK streams may be forced to spend excessive CPU time inflating gzip data, leading to timeouts or process slowdown. Fix: Fixed with 2be3903, Released in v1.1.0. Acknowledgements apko thanks Oleh Konko from 1seal for discovering and reporting this issue.
Recommended action: Upgrade to 1.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Path Traversal vulnerability was discovered in apko's dirFS filesystem abstraction. An attacker who can supply a malicious APK package (e.g., via a compromised or typosquatted repository) could create directories or symlinks outside the intended installation root. The MkdirAll, Mkdir, and Symlink methods in pkg/apk/fs/rwosfs.go use filepath.Join() without validating that the resulting path stays within the base directory. Fix: Fixed by d8b7887. Merged into release. Acknowledgements apko thanks Oleh Konko from 1seal for discovering and reporting this issue.
Recommended action: Upgrade to 1.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
It was discovered that the ld.so.cache in images generated by apko had file system permissions mode 0666: This issue was introduced in commit 04f37e2 ("generate /etc/ld.so.cache (#1629)")(v0.27.0). Impact This potentially allows a local unprivileged user to add additional additional directories including dynamic libraries to the dynamic loader path. A user could exploit this by placing a malicious library in a directory they control. Patches This issue was addressed in apko in aedb077 ("fix: /etc/ld.so.cache file permissions (#1758)") (v0.29.5). Acknowledgements Many thanks to Cody Harris from H2O.ai for reporting this issue.
Recommended action: Upgrade to 0.29.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Exposure of HTTP basic auth credentials from repository and keyring URLs in log output Details There was a handful of instances where the apko tool was outputting error messages and log entries where HTTP basic authentication credentials were exposed for one of two reasons: 1. The%s verb was used to format a url.URL as a string, which includes un-redacted HTTP basic authentication credentials if they are included in the URL. 2. A string URL value (such as from the configuration YAML file supplied used in an apko execution) was never parsed as a URL, so there was no chance of redacting credentials in the logical flow. apko, as well as its companion library go-apk, have been updated to ensure URLs are parsed and redacted before being output as string values. PoC Create a config file like this apko.yaml: Then run: Observe instances of the password being shown verbatim in the log output, such as: Impact For users accessing keyring or APK repository content using HTTP basic auth,…
Recommended action: Upgrade to 0.14.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.