Database/Container, Kubernetes & orchestration

Red Hat Quay quay-builder-qemu: release workflow pins a third-party action to a mutable branch

CVSS 8.0CVE-2026-85469Container, Kubernetes & orchestrationcurated

Impact

The quay-builder-qemu release workflow references the upstream Noelware/docker-manifest-action at a mutable branch rather than a pinned commit, and exposes the default GitHub token to that step. Anyone who compromises the upstream action can run arbitrary code in the release job, exfiltrate the registry credentials it holds, and publish malicious quay-builder-qemu images. For an operator this is a supply-chain exposure in the registry that fronts their cluster images: a poisoned builder image runs with the privileges Quay's build subsystem is given, and images it produces are trusted downstream by every node that pulls from the registry.

Who can reach it

Compromise of the upstream third-party GitHub Action, or of a maintainer account able to move that branch. Not reachable by a tenant or by anyone on the operator's network - the exposure is in Red Hat's build pipeline and lands on operators through the images they pull.

What to do

Track the Red Hat advisory for CVE-2026-85469 and pick up rebuilt quay-builder-qemu images when Red Hat ships them; the fix is on the vendor's side, so there is no local patch to apply. Operators should verify the provenance and digests of quay-builder-qemu images already deployed and pin deployments to known-good digests. If you maintain your own forks of this workflow, pin third-party actions to full commit SHAs and drop the default token from that step.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-85469 https://access.redhat.com/security/cve/CVE-2026-85469 https://bugzilla.redhat.com/show_bug.cgi?id=2528219

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.