Every container your team built with apko may have silently installed attacker-controlled software — and the tool told you everything was fine.
Who's Affected — and Why It Matters to You
If you've never heard of apko, there's a good chance software you use every day has. apko is a widely-used open-source tool maintained by Chainguard that builds the container images powering cloud applications — the invisible boxes that run your bank's mobile backend, your company's internal apps, and critical infrastructure across the internet. Developers trust apko specifically because it's positioned as a secure-by-default alternative to traditional container builders. That reputation is now cracked.
The vulnerability, tracked as CVE-2026-42575 and rated HIGH severity with a CVSS score of 7.5, affects every version of apko prior to 1.2.7. That covers an enormous window of production container builds — potentially millions of images currently running in cloud environments worldwide. The impact isn't theoretical. Any organization that built containers using an HTTP (non-HTTPS) package repository, a third-party mirror, or a CDN-cached package source during that window has reason to audit what's actually inside those images.
What Actually Happened — In Plain English
Here's the analogy that makes this click: imagine you order a sealed, certified package from a trusted pharmacy. The courier arrives, hands you a box, shows you the official seal on the shipping manifest — and you sign for it. What you never do is open the box and check whether what's inside actually matches what the manifest says. The seal on the paperwork was real. The pills inside could be anything. That is exactly what apko was doing with software packages.
When apko builds a container image, it downloads a cryptographically signed index — essentially a master list — that says "package X should have this exact fingerprint." That signature check worked fine. The problem is what happened next: when apko actually went out and downloaded the individual software packages listed in that index, it never checked whether each package's fingerprint matched what the signed index promised. It calculated the fingerprint, it had the expected value sitting right there in memory, and then it just... didn't compare them. Mismatched packages were silently accepted and installed as if nothing was wrong. An attacker positioned between apko and the package source — through a hacked mirror server, a poisoned CDN cache, or a plain HTTP connection being intercepted — could swap in malicious code with zero alerts raised.
The result is a textbook supply chain attack. Your developers follow every best practice. They use signed indexes, they trust their toolchain, they see green checkmarks. And buried inside the container image shipping to production is code you never approved, never reviewed, and never knew was there. Backdoors, credential harvesters, cryptominers — the attacker's imagination is the only limit.
The Technical Anchor — For the Researchers in the Room
The flaw lives in getPackageImpl() inside apko's package fetching logic. The function correctly calls ChecksumString() to retrieve the expected hash from the signed APKINDEX and separately computes the SHA-256 hash of the downloaded .apk package's control data — but the comparison step between those two values is entirely absent. This is a checksum validation bypass stemming from an incomplete signature verification chain: the index is verified, but package-level integrity is never enforced. The class of bug is deceptively simple — a validation step that was coded up to the point of comparison and then stopped. CVSS 7.5 (HIGH), no authentication required, network exploitable.
Has Anyone Been Hit? Who Found This?
As of publication, no confirmed active exploitation has been reported in the wild. Security teams should not treat that as reassurance — supply chain compromises of this nature are exceptionally difficult to detect after the fact, which means "no confirmed victims" often means "no confirmed detection." The nature of the attack is silent by design; if an attacker exploited this window, the evidence lives inside container images that may already be running in production or may have been cycled out entirely.
The vulnerability was identified through code-level review of apko's package verification logic. Given that apko is central to Chainguard's hardened container ecosystem — a product line that sells itself on security rigor — the discovery is particularly pointed. The project responded with a patch in version 1.2.7.
The risk surface is highest for any build pipeline that pulls packages over plain HTTP or uses third-party mirrors, which remain common in air-gapped enterprise environments and CI/CD pipelines optimized for speed over security posture.
What You Need to Do Right Now
Three steps, in priority order:
-
Update apko to version 1.2.7 or later — today. This is the only version with the checksum comparison fix in place. If you are using apko as a library dependency in your own tooling, check your
go.modor equivalent and pin to≥ 1.2.7. Runapko versionto confirm what's currently deployed in your build pipelines. -
Audit container images built before the patch, especially those using HTTP sources or third-party mirrors. Pull the image layers and compare installed package hashes against the official Chainguard or Alpine APKINDEX. Tools like
syftandgrypecan generate a software bill of materials (SBOM) from existing images, giving you a starting point to identify unexpected packages. Flag any image built against a non-HTTPS repository as high priority for rebuild. -
Enforce HTTPS-only package sources in all apko build configurations. While this doesn't retroactively fix the verification bug, HTTPS with certificate validation significantly raises the cost of a man-in-the-middle substitution attack. Audit your
.apko.yamland pipeline configs for anyhttp://repository URLs and replace them immediately. Consider adding repository URL policy enforcement to your CI/CD pipeline as a lint step going forward.
The Bigger Picture
CVE-2026-42575 is a reminder that supply chain security is only as strong as its weakest verification link. The security community has spent years evangelizing signed packages, signed indexes, and verified builds — and those controls matter. But a signature on a manifest is worthless if you never check whether the contents match. Trust the index, verify the package. Every time. The fact that a tool explicitly designed for secure container builds shipped without this comparison for so long suggests this class of partial-verification bug deserves its own dedicated audit pass in every package management system we rely on.
The patch is available. The path forward is clear. The question is how many builds happened in the gap.
CVE-2026-42575 | CVSS 7.5 HIGH | Fixed in apko 1.2.7 | No active exploitation confirmed as of publication