CVE-2026-85469 in Quay
Summary
by MITRE • 09/16/2026
A flaw was found in quay-builder-qemu. A remote attacker could exploit this by compromising the upstream `Noelware/docker-manifest-action` used in the release workflow, which is pinned to a mutable branch. This allows the attacker to inject arbitrary code, leading to the exfiltration of sensitive registry credentials or the publication of malicious images. The workflow also exposes the default GitHub token, increasing the severity of the compromise.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in quay-builder-qemu stems from a critical supply chain weakness within its CI/CD pipeline configuration rather than a traditional software code flaw. Specifically, the project relies on an upstream action named Noelware/docker-manifest-action which is pinned to a mutable branch instead of a specific immutable commit hash or version tag. In modern DevOps practices, pinning dependencies to mutable references such as main or master branches introduces significant risk because these references can be altered by maintainers or compromised attackers at any time without the consuming project's explicit knowledge. This lack of immutability means that if the upstream repository is breached or its maintainer account is taken over, an attacker can inject malicious code into the action script. When quay-builder-qemu executes this workflow, it unknowingly runs the tampered code with elevated privileges granted by the CI/CD environment.
The operational impact of this vulnerability is severe due to the nature of container registry operations and credential handling. By exploiting the mutable dependency, a remote attacker can execute arbitrary commands within the build runner context. This capability allows for two primary malicious outcomes: the exfiltration of sensitive credentials associated with the quay.io registry or other connected services, and the publication of compromised or backdoored container images to public repositories. The theft of registry credentials enables attackers to further infiltrate infrastructure, modify existing software distributions, or disrupt service availability by deleting critical assets. Conversely, publishing malicious images allows for a widespread supply chain attack where downstream consumers pulling these images inherit the compromise, potentially leading to lateral movement within their own networks and data breaches.
Compounding this issue is the exposure of default GitHub tokens during the workflow execution. CI/CD systems often provide automatic authentication tokens with permissions scoped to the repository or organization. When combined with the ability to run arbitrary code via the compromised action, these exposed credentials significantly amplify the blast radius of the attack. An attacker can leverage these tokens not only to exfiltrate data but also to modify other repositories within the same GitHub organization, create new branches, or deploy additional malicious actions that persist beyond the initial compromise. This creates a cascading failure scenario where a single weak dependency leads to broad organizational security degradation.
To mitigate this vulnerability, immediate remediation requires updating the workflow configuration to pin all third-party actions to specific immutable commit SHAs rather than mutable branch names. This ensures that even if an upstream repository is compromised, the consuming project will continue to use the last known secure version until it is manually updated and reviewed. Additionally, organizations should implement strict permission scopes for CI/CD tokens, adhering to the principle of least privilege by restricting token access to only what is necessary for the build process rather than using default full-access tokens. Enabling branch protection rules on upstream dependencies where possible and regularly auditing third-party actions for security best practices are also essential steps in hardening the software supply chain against such injection attacks.