CVE-2026-85469: Quay-builder-qemu: quay-builder-qemu: release workflow uses third-party action pinned to mutable @master with registry credentials in scope
Release workflow uses third-party Action pinned to mutable @master with registry credentials in scope
CWEs: CWE-1357, CWE-494, CWE-829 CVSS: 8.0 (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H) Component: quay/quay-builder-qemu
Description The build-and-publish job logs in to quay.io with secrets.QUAYUSER / secrets.QUAYTOKEN (lines 32-37) and later invokes Noelware/docker-manifest-action@master (line 91). Pinning a third-party Action to a branch ref means the executed code is whatever the upstream maintainer (or anyone who compromises that repo) pushes next; it is re-resolved on every run. Because docker/login-action has already persisted registry credentials in ~/.docker/config.json, any code injected into the Noelware action can read and exfiltrate the Quay push token or push arbitrary images to quay.io/projectquay/quay-builder-qemu. The workflow also lacks a permissions: block, so the default GITHUBTOKEN is available to the same step.
Affected Locations - .github/workflows/build-and-publish.yaml:90-98 - .github/workflows/build-and-publish.yaml:32-37
Attack Pattern Upstream compromise of Noelware/docker-manifest-action master branch leads to exfiltration of the quay.io push token / publication of a trojaned quay-builder-qemu image consumed by all Quay build executors.
Remediation Pin the third-party Action to a specific commit SHA. Add a top-level permissions: block restricting GITHUBTOKEN to the minimum required scope.
--- Source: Ex-Wing security assessment, finding FIND-001
Other sources
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.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Add a top-level `permissions:` block to the workflow file to restrict `GITHUB_TOKEN` to the minimum required scope (workflow currently lacks a `permissions:` block, so the default token is available to the affected step that invokes the third-party Action).
.github/workflows/build-and-publish.yaml permissions (top-level GITHUB_TOKEN scope) = restricted minimum required scope - Compensating control
Because the workflow logs in to `quay.io` (using `secrets.QUAY_USER` / `secrets.QUAY_TOKEN`) and the third-party Action executes with access to persisted registry credentials in `~/.docker/config.json`, rotate/replace `secrets.QUAY_TOKEN` (and any related registry credentials) after pinning and scope-restricting, to invalidate any potentially exfiltrated push token.
Event History
Frequently Asked Questions
Which workflow runs are exposed?
The exposure is in the build-and-publish job, where Quay credentials are used before Noelware/docker-manifest-action@master is invoked. The affected workflow locations are .github/workflows/build-and-publish.yaml lines 32-37 and 90-98.
What would an attacker need to exploit this?
An attacker would need control of, or the ability to compromise, the Noelware/docker-manifest-action master branch so that malicious action code is resolved during a workflow run. The action is re-resolved from the mutable branch on every run.
What could compromised action code access or change?
It could read the Quay credentials persisted in ~/.docker/config.json and exfiltrate the Quay push token. It could also push arbitrary images to quay.io/projectquay/quay-builder-qemu; the same step also has the default GITHUB_TOKEN because the workflow has no permissions block.