Red Hat Quay CVE-2026-123710 (9.8): an unauthenticated client can install its own registry signing key and pull or overwrite any private image; no fixed build yet
- Why it works: per Bugzilla,
/v2/authmints an anonymous token whose audience comes from the client'sserviceparameter; the key server accepts it for rotation at/keys/services/quay/keys/<kid>without checking what it was issued for, copies the signer's approval to the new key and stores it with no expiry. - Do now: block the
/keysservice-key endpoints at your proxy or load balancer so only trusted internal Quay components reach them; review logs and the service key list for unexpected keys and remove them. - Caveats from Red Hat: deleting a rogue key doesn't stick until a fixed build is deployed, because the anonymous request can install a new one; resetting passwords or robot tokens doesn't revoke a rogue key.
- Fix status: SecurityWeek reports fixes for this and CVE-2026-110697 were merged into the Quay GitHub repo on Nov 11, but Red Hat hasn't named a fixed release.
- Found by Red Hat's Dave O'Connor.
Sources: Red Hat solution 7149923: CVE-2026-123710 Identifying and remediating unauthorized signing keys in Red Hat Quay (updated Nov 11, 2026) · Red Hat Bugzilla 2568072 (CVE-2026-123710) · SecurityWeek: Critical Red Hat Quay Vulnerability Could Expose Private Container Images (Nov 12, 2026)