TL;DR: CVE-2026-54174 affects chainguard.dev/apko versions earlier than 1.2.9 and chainguard.dev/melange earlier than 0.50.4, where signed APK metadata was checked but payload bytes could still be swapped in build pipelines, according to Corgea. The flaw shows why provenance controls must verify the installed package contents, not just the index and control metadata.
At a glance
What this is: CVE-2026-54174 exposed a package integrity gap in apko and melange, where control metadata validation did not fully prove the bytes installed into an OCI image.
Why it matters: Platform, AppSec, and supply-chain teams need to treat package payload verification as a separate control from index and signature checks, especially in CI pipelines that fetch from mirrors or caches.
Context
CVE-2026-54174 is a package integrity failure, not a malicious-package discovery. The trust problem sits in build pipelines that assumed signed repository metadata was enough to prove what actually landed in the image filesystem, which is a classic provenance gap in modern OCI delivery.
The identity angle is indirect but real: build systems, package managers, and CI runners act as non-human identities that make trust decisions on behalf of the organization. When those workflows validate the wrong layer, the resulting image can inherit attacker-controlled content while still appearing compliant at the metadata layer.
Key questions
Q: What fails when a build tool verifies package metadata but not the payload bytes?
A: The trust model fails at the unpack step. A signed index or control section can still look valid while the data section has been swapped in transit or cache, which means the image builder may install different files from those the metadata implied. The fix is to verify the installed payload against the package datahash before expansion.
Q: Why do mirror and cache hops increase package integrity risk in CI pipelines?
A: They add untrusted or semi-trusted transfer points between repository metadata and the final filesystem contents. If an attacker can poison a cache or intercept a fetch, they may preserve the outer metadata while changing the payload bytes that the build system expands into the image. That is why provenance must cover the full fetch path.
Q: How can teams tell whether payload integrity verification is actually working?
A: The easiest test is to tamper with a known package payload in a controlled environment and confirm the build fails before unpacking. If the pipeline only rejects bad metadata but still installs altered bytes, payload integrity is incomplete. A working control checks the actual package content hash and stops substitution before image creation.
Q: What should organisations do when package provenance checks are limited to repository metadata?
A: They should treat the verification model as incomplete and close the gap with payload hashing, rebuild rules, and stricter trust decisions around mirrors and caches. In practice, that means no image should be promoted unless the installed bytes are proven to match the package's declared payload.
Technical breakdown
Why signed package metadata was not enough
apko and melange verified the control metadata linked to a signed APKINDEX, but that only established package identity and repository metadata integrity. The package format also carries a data hash for the payload that is actually unpacked into the image. If the build system checks only the control layer, an attacker who can tamper with transit or cache contents can substitute files without breaking the earlier verification step. The vulnerability is therefore a verification-boundary failure, not a cryptographic absence.
Practical implication: Treat repository metadata validation and payload verification as separate controls in your build chain.
How payload substitution can happen in CI and mirror paths
The attack path depends on an intermediate trust boundary. A compromised mirror, poisoned cache, or man-in-the-middle position can serve a package whose control metadata still looks valid while the payload bytes differ from what the package’s own datahash expects. The build tool then expands those substituted files into the image, so the final artifact inherits attacker-controlled content even though the upstream index passed verification. This is a supply-chain integrity issue because the risk sits between fetch and unpack, not at package publication time.
Practical implication: Map every package-fetch hop in CI so you know where payload tampering can occur before image assembly.
Why .PKGINFO is the missing second proof
The fix adds an explicit comparison between the payload bytes and the hash recorded in .PKGINFO. That matters because .PKGINFO already contains the datahash needed to prove the installed content matches the package’s declared payload. In other words, the format had sufficient material for end-to-end verification, but the vulnerable path stopped after the metadata check. The corrected model is dual validation: the signed index confirms package identity, and the package datahash confirms the actual filesystem contents.
Practical implication: Require builders to validate payload hashes, not just signed package indexes, before installing artifacts.
Threat narrative
Attacker objective: The attacker aims to get modified package contents baked into trusted OCI images without breaking the earlier metadata verification step.
- Entry occurs when an attacker can tamper with package delivery through a poisoned cache, compromised mirror, or intercepting network path.
- Credential or metadata trust is abused when the build tool accepts signed control information without proving the payload bytes match the package's declared datahash.
- Impact occurs when substituted package files are expanded into the final image filesystem and downstream artifacts inherit attacker-controlled content.
Breaches seen in the wild
- CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Payload integrity is the real trust boundary in modern build pipelines: package ecosystems do not fail only at publication, they fail where builders decide which bytes to install. Corgea's analysis shows that signed metadata can still leave a substitution window if the payload hash is never checked. For practitioners, the control question is no longer whether the package was indexed correctly, but whether the files that reached the filesystem were independently proven.
CI runners are governance-relevant non-human identities: build systems routinely fetch, verify, and expand artifacts on behalf of the organisation, so they are making identity-bound trust decisions at machine speed. That makes payload verification part of NHI governance, not just packaging hygiene. When a runner trusts the wrong layer, the mistake is operationally equivalent to giving the pipeline more authority than the provenance model can justify.
Package integrity gaps create provenance debt: once a build tool can install bytes that were never checked against the package's own payload hash, the organisation inherits an artifact whose trust story is incomplete. The problem is not limited to one vulnerability number; it reflects a broader pattern in which provenance checks certify the envelope but not the contents. Teams should treat this as a signal to tighten artifact attestation, mirror trust, and rebuild discipline.
From our research library:
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
- Read next: CI/CD Pipeline Identity Security Guide
What this signals
Payload verification is now a build-governance issue, not a packaging footnote: once builders can accept one layer of trust and ignore the layer that actually lands on disk, image provenance becomes conditional rather than assured. Teams should assume that mirror and cache trust must be explicitly governed, not inherited from repository signatures.
Package integrity debt accumulates fastest where CI runners assemble release artifacts: those runners behave like non-human identities that can import, expand, and publish content with very little human review. The control answer is to move trust checks closer to installation time, where the bytes that matter can still be rejected.
For practitioners
- Upgrade vulnerable build tools Move chainguard.dev/apko to 1.2.9 or later and chainguard.dev/melange to 0.50.4 or later, then rebuild any image pipelines that consumed older releases.
- Verify payload hashes in build pipelines Confirm that your package verification step checks the package datahash, not only the signed APKINDEX or control section metadata.
- Review mirror and cache trust paths Inventory every mirror, cache, and repository hop used by OCI builds so you can see where package bytes could be altered before unpacking.
- Rebuild downstream images from trusted inputs Treat affected images as potentially tainted until they have been rebuilt from fixed tooling and reverified from source to filesystem contents.
Key takeaways
- CVE-2026-54174 exposed a verification gap between signed package metadata and the payload bytes installed into OCI images.
- The flaw matters because CI runners, mirrors, and caches can preserve trust in the index while altering the content that becomes part of the final filesystem.
- Teams should rebuild affected images with fixed tooling and require payload hash verification before any package is expanded.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-06 — Insecure Cloud Deployment Configurations | The flaw sits in image-build pipelines and trust boundaries around package expansion. |
| NHI-02 — Secret Leakage | Package substitution in CI can carry attacker-controlled files into trusted artifacts. | |
| Recommendation — Harden build pipelines so package verification covers the actual payload before image assembly. Scan build workflows for paths where unverified package contents can enter release images. | ||
| MITRE ATT&CK | TA0001;TA0006;TA0010 — Initial Access; Credential Access; Exfiltration | The threat path uses tampering or interception before payload expansion into images. |
| Recommendation — Map package tampering scenarios to initial access, credential access, and exfiltration techniques in detection planning. | ||
| CIS Controls v8 | CIS-5 — Account Management | Build systems and pipeline identities need strict lifecycle control in delivery workflows. |
| Recommendation — Review service accounts that fetch and expand packages so only approved pipeline identities can install artifacts. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Pipeline authorization determines which builders can consume and install packages into images. |
| Recommendation — Restrict package-fetch and image-build permissions to the minimum set of approved pipeline identities. | ||
Key terms
- Payload Integrity Verification: Payload integrity verification confirms that the bytes installed into a build or runtime artifact match the package's declared content hash. It closes the gap left by metadata-only checks, which can prove package identity without proving the exact files that were unpacked.
- Package Datahash: A package datahash is the cryptographic value that represents the actual payload bytes a package will install. It is distinct from metadata hashes that describe the package record, and it is the control that proves the installed contents were not altered in transit or storage.
- Build Pipeline Trust Boundary: A build pipeline trust boundary is the point where code, credentials, and automation meet during software delivery. It is a control boundary because compromise there can spread from package installs into release systems, repositories, and cloud environments if secrets are present and privileges are broad.
- Action Provenance: Action provenance is the record of who initiated a task, which identity executed it, what tool was used, and what decision was made at runtime. It is essential when delegated work crosses systems because it preserves accountability even when the original request and the final action are separated by many steps.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for security teams that need a stronger control model for machine identities, secrets, and delegated trust.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org