Severity: Critical | Priority: 1
Red Hat has disclosed a critical flaw in Quay, its private container image registry, tracked as CVE-2026-123710 (CVSS 9.8). Quay’s key server holds the signing keys that Quay uses to issue access tokens for container images. It is meant to accept a new key only from a trusted internal component. The flaw is that it checks only that a request carries a token signed by Quay with the right audience. It does not check what that token was issued for. Ordinary registry tokens pass the check, and Quay hands these out on request, including to anonymous users when anonymous access is enabled (the default in recent versions). As a result, an attacker with no account, or with any account when anonymous access is off, can install a signing key of their own that never expires.
With that planted key, the attacker can create valid access tokens for any repository in the registry. They can pull every private image, including any credentials, keys or configuration baked into it, and push or overwrite images. Poisoned images could then be deployed into production systems that trust the registry. The planted key survives restarts, password resets and robot token changes, and the attack can also delete the keys that legitimate Quay instances use, breaking authentication for everyone. Every Quay 3 and Quay 5 version is affected, including standalone installations, the Quay Operator on OpenShift and the mirror registry for Red Hat OpenShift. No exploitation has been reported so far.
Administrators should upgrade to the fixed Quay build for their branch, for example 3.18.3, 3.17.7 or 3.16.7, and confirm the running pods have restarted on the new image. Until then, block the /keys path at the proxy or load balancer for everything except trusted internal components. Turning off anonymous access alone does not protect you. With /keys blocked, audit the approved service keys through the superuser API. Search the audit log for service_key_rotate, service_key_create or service_key_delete events with no expiration date, and remove any key you do not recognise. If a planted key is found, treat every private image and every secret inside it as exposed. Rotate those secrets, check recently pushed images for tampering, and repeat the review on staging and disaster-recovery registries that share credentials with production.