Red Hat Quay CVE-2026-123710: Registry Takeover and Fixes

Last updated: 15 November 2026. This is a developing issue; see theupdate logand re-check Red Hat's advisory before acting.

Red Hat Quay, the container registry that many teams run on-premises and on OpenShift, has a critical flaw in the way it manages its own signing keys. CVE-2026-123710 is scored 9.8 (Critical) and, as described by Red Hat, lets a client with no account install its own trusted signing key. After that it can read private images and overwrite tags. If you run Quay, the registry itself is the thing at risk, and so is every system that pulls from it.

This article explains in plain terms what the bug is, who is affected, what to do first (before and after patching) and how to reduce your exposure to a poisoned image. I could not run Quay itself, so the vulnerability details come from Red Hat and security press coverage, and I say which is which. One of the mitigations, restricting the key endpoint at your reverse proxy, I did test with nginx.

The short version

What: CVE-2026-123710, CWE-1287 (improper validation of the specified type of input), in Quay's service key server. Red Hat's CVSS 3.1 score is 9.8 with the vector AV:N/AC:L/PR:N/UI:N: network, low complexity, no privileges, no user interaction.
Impact: an attacker can install a signing key that Quay trusts, then mint tokens that give read and write access to repositories. That means exposure of private images and any secrets inside them, and the ability to replace images that other systems pull.
Affected: Red Hat Quay 3 and 5, including standalone deployments, the Quay Operator on OpenShift and the mirror registry for OpenShift, according to The Hacker News' reading of Red Hat's data.
Exploited in the wild: none of the coverage I read says so, and one vendor write-up lists "no public exploit". That can change quickly.
Fix: upstream fixes were merged on 11 November. Red Hat has published fixed builds for several Quay 3 branches. See the version note below.

How the attack works

Quay signs the tokens that authorize registry access. The signing keys are managed by a service key server, and keys can be rotated through an API. According to The Hacker News, the key server accepts a rotation request if it carries a token signed by a trusted key with the expected audience and issuer. It does not check that the token was issued for key rotation.

That is the gap:

An unauthenticated client requests an anonymous registry token from the auth endpoint (/v2/auth) and chooses the audience.
That token passes the key server's checks, so the client can ask the key server to add or rotate a key.
The attacker's key is accepted as trusted. It can be set with no expiry, and it survives restarts.
With that key the attacker can sign tokens that Quay honors for any repository, and can pull private images or push tampered ones under existing tags.
Red Hat's report also says the rotation deletes the legitimate instance key as a side effect, and the attacker's key can delete replacement keys. That can break legitimate pushes and pulls.

Two points from Red Hat that change what you might assume:

Turning off anonymous access does not protect you. Red Hat says any valid Quay account can still exploit the flaw.
Resetting passwords or regenerating robot tokens does not remove the attacker's key. The key lives in Quay's key store, not in a user credential.

A second flaw in the same fix: CVE-2026-110697

The same researcher, Red Hat's Dave O'Connor, found a related issue, scored 9.9. As The Hacker News describes it, the robot-account listing code builds a SQL LIKE pattern from the namespace name without escaping wildcards. In SQL LIKE, an underscore matches any single character, so a crafted namespace can match another tenant's namespace and return its robot accounts with their tokens. The only prerequisite reported is the ability to create a namespace. Stolen robot tokens allow reading, pushing or overwriting another tenant's images.

This one is easier to understand if you have written SQL: it is the same class of mistake as forgetting that % and _ are special inside a LIKE. Escape them, or use an exact match when you mean one.

Which versions are fixed?

This is the part to verify with Red Hat directly, because the sources disagree on timing:

The Hacker News reports fixed builds for eight Quay 3 branches. It also notes that, when it checked, the CVE entry still showed no fix, and that the second CVE was not listed in the individual advisories.
A third-party aggregator's summary of Red Hat advisory RHSA-2026:99026 (Red Hat Quay 3.17.7, published 11 November, updated 13 November) lists both CVE-2026-123710 and CVE-2026-110697 among 25 fixed CVEs. I could not open Red Hat's errata page itself, so confirm it on Red Hat's site.
No fixed Quay 5 build was identified in the sources I read.

In practice: find your Quay version, look up the errata for your branch on the Red Hat Customer Portal, and upgrade to the build that lists CVE-2026-123710. If your branch has no fixed build yet, use the mitigations below and follow Red Hat's solution article referenced in the coverage.

What to do first

1. Restrict the key endpoint

Red Hat's mitigation is to restrict access to the /keys endpoint at the proxy or load balancer, so that only trusted internal components can reach it. Here is an nginx example. Adjust the network range to match your internal services:

location /keys { allow 10.20.0.0/16; # internal components that need the key server deny all; proxy_pass http://quay_backend; }

I tested this pattern with nginx 1.24 in front of a dummy upstream. From a client outside the allowed range, all of these returned 403: /keys, /keys/services/quay/keys/abc, //keys/x, /%6beys/x (URL-encoded) and /keysfoo (it is a prefix match), and so did a PUT. From an allowed client, the same path reached the upstream and returned 200. Things to note:

/KEYS (upper case) was not blocked; it reached the upstream. nginx matches paths case-sensitively. Whether Quay treats that path as the same endpoint I could not check, so test your own deployment and, if needed, deny at a broader level.
Replace quay_backend with your real upstream, and keep your existing proxy settings. This snippet is not a complete Quay configuration.
If another load balancer sits in front of nginx, the client address nginx sees is that balancer's. Configure real client IP handling, or apply the restriction on the outermost layer.
One vendor write-up also suggests limiting /v2/auth. Be careful: ordinary docker login and pulls go through the auth endpoint, so blocking it for clients will break normal use. Red Hat's stated mitigation names /keys only.

Check which parts of your own platform (Clair, build workers, operators) talk to the key server before you apply a deny rule, so you do not cut them off.

2. Look for planted keys

Red Hat's guidance is to review audit logs for service_key_rotate and service_key_delete events where the expiration_date is null, and to remove unrecognized approved keys. Legitimate service keys are normally expected to expire, so a key with no expiry added through the key server deserves attention. I cannot show you the exact query, because it depends on how you export Quay's audit log (the UI, the log database or your log shipper).

Two cautions from Red Hat's text: deleting a rogue key is not durable until you are on a fixed build, because the attacker can add it again, and compromise of a key means you should treat what that key could access as exposed.

3. Patch

Upgrade to a fixed build as described above. After the upgrade, repeat the audit-log and key review, since a key planted earlier would survive an upgrade unless you remove it.

Assume images may have been touched? Verify them

If your registry was reachable by untrusted clients while vulnerable, you cannot tell from the registry alone that a tag still points to what you built. The defense is not to trust tags at all.

Reference images by digest in Kubernetes manifests and deployment files: image: quay.example.com/org/app@sha256:<digest>. A digest identifies content; if someone overwrites a tag, a deployment pinned by digest still gets the original image or fails to pull.
Record the digest at build time, in your CI output, and compare it with what the registry serves now. Tools such as skopeo inspect or crane digest can read a digest from a registry. I have not run them against Quay.
Audit recent pushes and tag changes for ones you cannot match to a pipeline run.
Rotate secrets that were baked into images. Private images can contain credentials, and this flaw exposes private images. Rotating the Quay robot tokens alone is not enough, as noted above.
Consider image signing (for example Sigstore's cosign) so deployment can verify who built an image. That is a broader project and I did not test it here.

Who should worry most

Teams running Quay on a network reachable by many users, partners or the internet.
Multi-tenant installations, because of the second flaw.
Anyone whose CI/CD pulls base images or deploy images from Quay automatically. A swapped image is a supply chain attack on everything downstream.
OpenShift users on the integrated registry or the mirror registry, which are listed as affected by The Hacker News.

Red Hat's hosted Quay.io service was listed as already patched for the second CVE at the time of disclosure by one write-up; I found no equivalent statement for the first one, so check Red Hat's notice if you use the hosted service.

Common mistakes

Disabling anonymous access and considering the problem solved. Any valid account can still exploit it.
Rotating user passwords and robot tokens, but leaving a rogue signing key in place.
Deleting a suspicious key before patching, and not checking that it did not come back.
Blocking /v2/auth broadly and breaking normal logins.
Patching without checking that your branch's errata actually lists the CVE.
Pulling by mutable tags (:latest, :prod) when integrity matters.

Frequently asked questions

Is CVE-2026-123710 being exploited?

None of the sources I read says it is. One write-up lists no public exploit. Treat it as exploitable, because the attack needs no authentication and Red Hat has published the details.

Does it need an account?

No. Anonymous access, which is enabled by default according to one report, is enough. With anonymous access disabled, any valid account is enough, per Red Hat.

Is Quay 5 affected?

The Hacker News reports that Red Hat lists all Quay 3 and Quay 5 versions as affected. I found no fixed Quay 5 build in the sources, so ask Red Hat or check the advisory.

Will changing my passwords help?

No. The attacker's signing key is separate from user passwords and robot tokens, and it has to be removed from the key store.

Can I just block /keys and skip patching?

Blocking it reduces exposure, and it is Red Hat's recommended mitigation while you patch. It is not a replacement for the fix.

update log

15 November 2026: first version.
To recheck on each update: Red Hat's CVE page and errata for fixed versions per branch, any exploitation reports, a Quay 5 fix, and Red Hat's solution article for key removal.

Sources

Originally published on DEV Talk.