Red Hat discloses critical signing-key flaw in Quay

Red Hat disclosed two critical flaws in Quay this week, both rated near the top of the CVSS scale, both found by Red Hat’s Dave O’Connor. The first, CVE-2026-123710 (9.8), lets anyone who can reach a Quay registry plant their own permanent signing key and then read or overwrite private images in every repository. The logic behind it has been in Quay since its first public commit.

Quay signs the access tokens that authorize image pushes and pulls with keys it trusts. The key server will replace a key if the request carries a token signed by a trusted key with the expected audience and issuer, and it never checks that the token was actually issued for key rotation. Quay’s own /v2/auth endpoint hands out anonymous tokens signed with a trusted key, and the caller picks the audience. So the attacker asks Quay for a token, points it at the key server, and registers a key of their choosing with no expiry.

After that the registry accepts tokens signed with the attacker’s key for any repository. They can pull private images and whatever secrets or credentials are baked into them, and push or overwrite images that then propagate to every system that later pulls them. The planted key survives restarts until someone deletes it. It can also be used to delete the keys that running Quay instances rely on, at which point normal pushes and pulls start failing with authentication errors.

Anonymous access is on by default in Quay, and while it is on the attacker needs no account. Turning it off does not close the hole; any valid account can still run the same sequence, and Red Hat is explicit that a key planted this way keeps working after you disable anonymous access, reset passwords, or rotate robot tokens. Any Quay instance an untrusted client can reach is exposed, including internal registries, standalone installs, the Quay Operator on OpenShift, and the mirror registry for OpenShift.

The second flaw, CVE-2026-110697 (9.9), is a one-character SQL bug. The code that lists robot accounts builds a LIKE pattern from the namespace name without escaping wildcards, and in SQL LIKE an underscore matches any single character. A user who can create a namespace can name it so the underscore lines up with another tenant’s namespace, and the query returns that tenant’s robot accounts along with their decrypted tokens. The attacker needs no elevated privileges and the victim does nothing. With those tokens the attacker reads, pushes, or overwrites the other tenant’s images; where Quay is the integrated registry for OpenShift, Red Hat says stolen robot credentials can inject malicious images into CI/CD pipelines. Deleting the attacker’s namespace deletes the matching robot accounts, which can cut off systems that depend on them.

Red Hat has shipped fixed builds for eight Quay 3 branches and says Quay.io is already patched. The reporting around the advisories is uneven: when checked today the CVE entry for CVE-2026-123710 still listed every package as affected with no fix, and none of the eight advisories list CVE-2026-110697 even though its CVE page names them as the fixed releases. Red Hat lists every version of Quay 3 and Quay 5 as affected by both.

For the key flaw, the interim steps are specific. Block the /keys endpoint at the proxy or load balancer for everything except trusted internal components. Search audit logs for service_key_rotate and service_key_delete events with a null expiration_date, and remove any approved service keys you don’t recognize. None of this holds until the fixed release is running, because an attacker can add a new key the same way, so deleting one is temporary.

For the robot-account flaw, limit who can create organizations or namespaces containing an underscore, rotate robot tokens for any namespace that matches an underscore namespace, and watch for pushes and pulls that don’t match normal robot use. Red Hat is clear these reduce exposure but do not fix the flaw; updating is the only complete fix.

The upstream patch adds the rotation check the key server was missing, requires keys added through the key server to carry an expiry, and stops callers from choosing a token’s audience. The same change closes the robot-account search.