CVE-2026-42575: 
Wolfi vulnerability analysis and mitigation

CVE-2026-42575 is a package substitution vulnerability in Chainguard's apko tool, which is used to build and publish OCI container images from apk packages. The flaw exists in all versions prior to 1.2.7: apko correctly verifies the cryptographic signature on APKINDEX.tar.gz but never compares individually downloaded .apk packages against the checksums recorded in that signed index, allowing mismatched packages to be silently accepted. It was discovered by Oleh Konko from 1seal, privately reported, and published to the GitHub Advisory Database on April 23, 2026, with NVD publication on May 9, 2026. The vulnerability carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory).

The root cause is classified as CWE-345 (Insufficient Verification of Data Authenticity) and CWE-494 (Download of Code Without Integrity Check). While apko parses the Q1-prefixed base64 SHA-1 checksum from the signed APKINDEX via ChecksumString() and computes the downloaded package's control section hash, the getPackageImpl() function never performs a comparison between these two values — mismatched packages are silently accepted. The same gap existed in the cachedPackage() path, where on-disk cached control files were trusted based solely on their content-addressable filename without re-hashing the file contents. An attacker positioned to intercept or substitute download responses — via a compromised mirror, HTTP (non-TLS) repository, or poisoned CDN cache — can exploit this without any credentials or user interaction (GitHub Advisory, Fix Commit).

Successful exploitation allows an attacker to install arbitrary, attacker-controlled packages into OCI container images built with apko, directly compromising the integrity of the resulting images. Because apko is used in supply chain and CI/CD contexts to produce container images, malicious packages embedded at build time could propagate to all downstream deployments of those images, enabling persistent backdoors, credential theft, or further lateral movement within containerized environments. Confidentiality and availability are not directly impacted by this vulnerability, but the integrity impact is rated High given the potential for undetected supply chain compromise (GitHub Advisory).

No public proof-of-concept exploit code or evidence of in-the-wild exploitation has been reported as of the time of disclosure. The EPSS score is approximately 0.014% (0.02% per GitHub Advisory, 6th percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires the attacker to be in a position to substitute package download responses (e.g., via a compromised mirror, HTTP repository, or CDN cache poisoning), which adds meaningful precondition complexity despite the low CVSS attack complexity rating (GitHub Advisory).

1. Identify a target build pipeline: Locate an organization using apko versions prior to 1.2.7 to build OCI container images, particularly those fetching packages over HTTP or from third-party mirrors.
2. Position for package substitution: Compromise an apk mirror, poison a CDN cache serving apk packages, or perform a man-in-the-middle attack on an HTTP (non-TLS) repository used by the target's apko build environment.
3. Prepare a malicious .apk package: Craft a replacement .apk file containing arbitrary malicious content (e.g., a backdoored binary or a web shell) that differs from the legitimate package recorded in the signed APKINDEX.
4. Serve the malicious package: When apko requests the target .apk file during an image build, respond with the malicious package. Because apko verifies the APKINDEX signature but never compares the downloaded package's control hash against the signed index checksum, the substituted package is accepted without error.
5. Achieve persistence in built images: The malicious package is installed into the OCI container image. Any downstream deployment of that image will include the attacker-controlled package, enabling code execution, credential harvesting, or lateral movement within containerized workloads (GitHub Advisory, Fix Commit).

• Network: Unexpected or anomalous HTTP responses from apk mirrors during image builds; DNS resolution for apk repository hostnames resolving to unexpected IP addresses; traffic to unfamiliar CDN or mirror endpoints during CI/CD build jobs.
• File System: Container image layers containing packages whose SHA-1 control section hash does not match the checksum recorded in the corresponding signed APKINDEX; unexpected binaries or scripts present in built images that differ from expected package contents.
• Logs: apko build logs (prior to v1.2.7) showing no checksum mismatch errors even when packages were substituted — absence of error is not confirmation of integrity in vulnerable versions; CI/CD pipeline logs showing package downloads from unexpected or newly registered mirror domains.
• Process/Runtime: Unexpected processes or network connections originating from containers built with apko on vulnerable versions, particularly if those containers exhibit behavior inconsistent with their declared package manifest.

The primary remediation is to upgrade apko to version 1.2.7 or later, which introduces explicit verification of each downloaded .apk package's control section SHA-1 hash against the checksum recorded in the signed APKINDEX, and applies the same check to cached packages (apko v1.2.7 Release). As a workaround for environments that cannot immediately upgrade, restrict apko builds to use only HTTPS-served repositories from trusted, controlled mirrors to reduce the risk of package substitution via network interception. Organizations should also audit recently built images for unexpected package contents if they used vulnerable apko versions with HTTP repositories or third-party mirrors (GitHub Advisory).

The vulnerability was acknowledged by the Chainguard team (apko maintainers), with the fix credited to analyst antitree and the reporter Oleh Konko from 1seal. Social media activity was limited but present, with mentions on Bluesky and Mastodon highlighting the supply chain integrity implications of the missing checksum verification. Coverage appeared on several vulnerability tracking and security news aggregators shortly after NVD publication (GitHub Advisory).