Red Hat Quay CVE-2026-123710 (9.8): Anyone Who Can Reach /keys Can Plant a Signing Key and Rewrite Your Private Images. Patch, Then Prove Your Images Are Still Yours
If you run Red Hat Quay yourself, block the /keys endpoint at your proxy or load balancer today so only trusted internal components can reach it, update to the fixed Quay release for your branch, and then prove your images are still yours: compare the digests your clusters pull against your build records, and search Quay's audit log for service_key_rotate and service_key_delete events with a null expiration_date. Patching closes the door. It does not tell you whether someone already walked through it, and an image that was overwritten before you patched is still sitting in the registry, still trusted by every cluster that pulls from it.
What Red Hat says
Red Hat's CVE record for CVE-2026-123710, which we read in its machine-readable form, rates the flaw Critical with a CVSS 3.1 score of 9.8 (vector AV:N/AC:L/PR:N/UI:N, scored "draft"). Its description, in full: "An unauthenticated client can obtain an anonymous registry token with an audience it controls, present that token to the service key rotation endpoint, and install its own approved signing key with no expiry. Registry tokens signed with that key are accepted for any repository, allowing read and write access to private images and replacement of repository tags."
Red Hat's statement explains the mechanism. Key rotation "authenticates the caller only by verifying that the JWT is signed by an already approved service key with the expected audience and issuer, without checking that the token is a rotation credential. An anonymous token minted by /v2/auth satisfies that check. Installed keys inherit approval and can be created without an expiry, so forged registry tokens are accepted for any repository. Deployments where /keys is reachable by untrusted clients are affected."
The flaw was reported to Red Hat on Thursday, November 6 and made public on Wednesday, November 11 at 14:00 UTC, according to the CVE record's timeline. Red Hat credits Dave O'Connor of Red Hat with the discovery.
Does an attacker need a login?
Red Hat's CVSS vector says no privileges are required, and its statement says "unauthenticated attacker". Red Hat's remediation article (solution 7149923, "Identifying and remediating unauthorized signing keys in Red Hat Quay") adds the nuance: anonymous access is on by default, so while it is enabled an attacker needs no account at all, but "Turning off anonymous access doesn't protect you", because any valid Quay account can still exploit the flaw. Turning off anonymous access raises the bar from "anyone" to "anyone with an account". It is not a fix.
The same article warns that resetting passwords or regenerating robot tokens does not revoke a planted signing key. The key is the attacker's own; your credentials were never involved.
Which versions
Red Hat's record lists Red Hat Quay 3 (the quay-rhel8 and quay-rhel9 images) and Red Hat Quay 5 (quay-rhel9) as affected, with no version range: every version. The remediation article names three deployment shapes: standalone Quay on Podman or Docker, Quay deployed by the Quay Operator on OpenShift, and the mirror registry for Red Hat OpenShift. That last one matters because people forget they run it; it is the small Quay that disconnected OpenShift installs use to hold their mirrored release images.
The fixed builds are eight Quay 3 releases: 3.9.28, 3.10.28, 3.12.24, 3.14.10, 3.15.9, 3.16.7, 3.17.7 and 3.18.3. We take that list from Red Hat's record for the companion flaw fixed in the same releases, CVE-2026-110697, whose mitigation names them. The CVE-2026-123710 record itself, as we read it on November 12, still marks all three Quay packages as "Affected" with no fix listed, and Red Hat's per-CVE errata lookup returned no advisory for it. The Hacker News reports that each of the eight advisories does list CVE-2026-123710; we could not confirm that from Red Hat's own data, so check the errata for your branch before you close the ticket. We saw no fixed Quay 5 build named anywhere.
The upstream fix is commit 094cfb024f01 in the quay/quay repository, titled "Fix CVE-2026-110697 and CVE-2026-123710", committed November 11. Among the files it changes are the key server endpoints, the service key model and the /v2/auth token code.
Is quay.io affected?
Red Hat's CVE-2026-123710 record says nothing about quay.io, the hosted service. Its record for the companion flaw, CVE-2026-110697, says "Red Hat has already fixed Quay.io." We would not stretch that sentence to cover the signing-key flaw; Red Hat did not write it there. If you push private images to quay.io, the risk to you sits with Red Hat's operation of the service, and the digest check below still applies.
Is it being exploited?
Red Hat claims no exploitation, and neither does The Hacker News. CVE-2026-123710 is not in CISA's Known Exploited Vulnerabilities catalog as of version 2026.11.10.
Why this one is a supply-chain problem, not a registry problem
A registry is the place every cluster agrees to trust. With a planted signing key, an attacker can mint a token for any repository and push a new image under an existing tag. Nothing on the consuming side looks wrong: the pull succeeds, the tag is the one in the deployment manifest, the registry is the one your pull secret names. Every cluster, CI runner and developer laptop that pulls by tag takes the replacement on its next pull or restart. The read side matters too: private images often carry baked-in configuration, internal hostnames and, too often, secrets.
So the patch is the first half. The second half is evidence that nothing changed while the door was open, and the flaw's logic, according to The Hacker News's reading of Red Hat's bug report, has been in Quay since its first public commit. You do not know how long the window was. Assume it was long.
What to do, in order
Today, before you patch: restrict /keys at the proxy or load balancer to trusted internal components, as Red Hat's mitigation says. On OpenShift, that means the route or ingress in front of Quay, not just a network policy inside the namespace.
Update to the fixed release for your branch (3.9.28, 3.10.28, 3.12.24, 3.14.10, 3.15.9, 3.16.7, 3.17.7 or 3.18.3). Red Hat says deleting a rogue key "is not durable until a fixed build is deployed, because the anonymous request can install a new key". Patch first, then clean, or you will clean twice.
Hunt for planted keys. In Quay's audit log, look for service_key_rotate and service_key_delete events with a null expiration_date. In the superuser service keys panel, list every approved key and remove any you cannot tie to a component you run. A legitimate Quay deployment has a small, known set of service keys.
Prove your images. For every repository that production pulls from, compare the manifest digest each tag points to now against the digest your build system recorded when it pushed. Tag history in Quay shows when a tag moved; a move with no matching build is the finding. If you sign images with cosign or a similar tool and enforce verification at admission, a forged push without your signing key fails that check, which is one more reason to turn enforcement on. If you deploy by digest rather than by tag, your running workloads were pinned, but check what the tags point to anyway, because the next deploy resolves them.
If you find a planted key or a moved tag, treat it as an incident: assume private images were read, rotate any secret baked into an image, and rebuild affected images from source rather than trusting what is in the registry.
While you are in there, patch CVE-2026-110697 too (same releases): a namespace name with an underscore can leak other tenants' robot tokens on multi-tenant Quay.
How we know, and what we could not check
We read Red Hat's CVE records for CVE-2026-123710 and CVE-2026-110697 through Red Hat's security data API and its CSAF VEX file, the CVE record at cve.org, Red Hat's Bugzilla entry 2568072, the visible part of Red Hat solution 7149923 (the detection and removal steps are behind a Red Hat login and we did not read them), the upstream commit on GitHub, and CISA's KEV catalog. The Hacker News article was our lead and the only source for the claim that each errata lists this CVE.
Edge check: Red Hat names two HTTP paths, /keys and /v2/auth. Our edge-shield block log, edge canaries and origin honeypot showed zero requests to Quay's key server paths (anything under /keys/services) and zero to the bare /v2/auth token endpoint since October 13, across 353,159 edge block events, 55,631 canary records and 714 origin captures. The broader patterns did match 74 blocked requests from 23 IPs, but those were credential-file sprays such as /keys/service-account.json and /keys/firebase-adminsdk.json, plus generic login and register probes under /v2/auth/. That is ordinary secret hunting, not Quay exploitation, and we do not count it as a sighting. We do not run Quay, so our edge is a weak instrument for this flaw: zero here means nobody sent Quay key-rotation requests at our domains, not that nobody is scanning for Quay.
Indicators: none published in the sources we read, so we added nothing to the feed.
Sources
Red Hat, CVE-2026-123710: access.redhat.com/security/cve/CVE-2026-123710
Red Hat, CVE-2026-110697: access.redhat.com/security/cve/CVE-2026-110697
Red Hat solution 7149923, "Identifying and remediating unauthorized signing keys in Red Hat Quay": access.redhat.com/solutions/7149923
Red Hat Bugzilla 2568072: bugzilla.redhat.com/show_bug.cgi?id=2568072
CVE record: cve.org/CVERecord?id=CVE-2026-123710
Upstream fix: github.com/quay/quay/commit/094cfb024f01
The Hacker News, "Critical Red Hat Quay flaw lets attackers…": thehackernews.com/2026/11/critical-red-hat-quay-flaw-lets.html
CISA Known Exploited Vulnerabilities catalog, version 2026.11.10
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Comments