Red Hat Quay CVE-2026-123710 Explained: 9.8 Signing-Key Flaw Lets Attackers Forge Tokens and Steal Private Images

Illustrative image: the Red Hat logo. Red Hat Quay is Red Hat's enterprise container registry. Image: Red Hat, public domain, via Wikimedia Commons.

TL;DR: Red Hat Quay CVE-2026-123710 explained in one line: a 9.8-rated flaw lets an attacker with no account take over a Quay registry's token signing, forge tokens for any repository, and read private container images or replace the tags your servers pull. There is no fixed released version yet, so the urgent step is to block untrusted access to Quay's /keys endpoint and check your audit logs for a rogue signing key.

Key Highlights

• CVE-2026-123710 scores 9.8 (critical). It affects Red Hat Quay 3 and Quay 5 — the enterprise registry that stores and serves the container images your apps deploy from.
• No login needed. An unauthenticated attacker can install their own approved signing key with no expiry date, then mint registry tokens for any repository.
• The damage is twofold: private images (and any credentials or secrets baked into them) can be read, and image tags can be replaced so other systems download tampered images.
• A second flaw shipped in the same batch: CVE-2026-110697 (9.9) leaks robot-account tokens across tenants in multi-tenant registries — but unlike the first flaw, it already has fixed releases.
• No exploitation has been reported yet and neither flaw is in CISA's Known Exploited Vulnerabilities list as of 12 November — but the fixes for the 9.8 flaw only landed in the project's code on 11 November, so patching and checking cannot wait.

What happened?

Red Hat disclosed CVE-2026-123710 on 11 November 2026, and the US National Vulnerability Database published the record the same day. SecurityWeek reported it on 12 November. The flaw sits in Quay's service key server — the component that manages the signing keys used to prove a registry token is genuine.

Quay is the container registry many engineering teams run to store, manage and distribute container images, either standalone, through the Quay Operator on OpenShift, or as the mirror registry for Red Hat OpenShift. If your team builds container images and deploys them through a private registry, Quay may be the piece in the middle — which is exactly why a signing-key takeover matters: whoever controls token signing controls who can read or write every repository in that registry.

The flaw was discovered by Red Hat's own Dave O'Connor and reported through Red Hat Bugzilla (report 2568072, filed 6 November). The same researcher also found the second flaw in this batch, CVE-2026-110697.

Red Hat Quay CVE-2026-123710 explained: how the signing-key takeover works

The attack is short, and that is what makes it dangerous. In Red Hat's own words, "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."

Step by step, in plain language:

1. Get an anonymous token. When anonymous access is enabled, anyone can obtain a registry token from Quay's /v2/auth endpoint — no account required — and choose the token's audience value themselves.
2. Present it as a rotation credential. The key-rotation endpoint (/keys) is supposed to accept only special rotation credentials. But it checks only that the token is signed by an already-approved service key and carries the expected audience and issuer. It never checks that the token actually is a rotation credential — and the anonymous token passes that weak check.
3. Install a rogue signing key. The attacker registers their own signing key, which Quay now treats as approved. Because the attacker controls the key, they can create it with no expiry date.
4. Forge tokens for anything. Registry tokens signed with the rogue key are accepted for any repository. The attacker can now read private images — including any credentials or secrets stored inside them — and overwrite image tags, so systems that later pull those images download the attacker's content.

Two details make the flaw worse than a one-off break-in. First, the rogue key survives registry restarts unless someone removes it. Second, rotating keys — the normal recovery move — deletes the legitimate instance key as a side effect, and the attacker's key can delete replacement keys too. That can also block legitimate users from uploading or downloading images, turning a security incident into an outage.

And the obvious quick fixes do not work. Turning off anonymous access does not protect you, because any valid Quay account can still run the same attack. Changing passwords or regenerating robot tokens does not help either, because neither action invalidates an unauthorised signing key. Only restricting access to the /keys endpoint and deploying a fixed build close the hole — and Red Hat warns attackers could reinstall a rogue key until a fix is deployed.

The second flaw: CVE-2026-110697 steals robot tokens across tenants

The same 11 November batch contains a second critical Quay flaw, and it is worth knowing about even though the headline flaw is the 9.8. CVE-2026-110697 scores 9.9 and is a SQL injection flaw in Quay's robot-account listing function: it builds a SQL LIKE pattern from user-controlled namespace names without escaping wildcard characters.

Flaw	Score	What it does	Who can exploit it	Fix status
CVE-2026-123710 — signing-key takeover	9.8 critical	Installs a rogue signing key; forges tokens for any repository; reads private images, replaces tags	Unauthenticated (or any valid account)	No fixed released version identified yet; fixes merged to GitHub 11 Nov
CVE-2026-110697 — robot-token leak	9.9 critical	Underscore in a namespace name acts as a SQL wildcard, matching other tenants' namespaces and leaking their robot accounts and decrypted tokens	Authenticated, low privileges, no victim interaction	Fixed releases published: 3.9.28, 3.10.28, 3.12.24, 3.14.10, 3.15.9, 3.16.7, 3.17.7, 3.18.3; Quay.io already fixed

For the second flaw, an attacker creates a namespace whose name contains an underscore that collides with an existing one. The underscore acts as a single-character SQL LIKE wildcard, so the attacker can list and steal the victim tenant's robot-account tokens, then read, push or overwrite that tenant's container images. In OpenShift environments where Quay serves as the integrated registry, stolen robot credentials can inject malicious images into CI/CD pipelines — a direct supply-chain risk. Multi-tenant Quay deployments are common in enterprises that share one registry across teams and in service providers hosting several customer organisations.

Illustrative image: a data-centre server room. Quay registries typically run on infrastructure like this, serving the images production systems pull. Image: Ana Las Heras, CC BY-SA 4.0, via Wikimedia Commons.

Why it matters for readers

A container registry is a trust anchor. Every server, CI job and Kubernetes cluster that pulls an image trusts the registry to hand over exactly what was published. A signing-key takeover breaks that trust at the root: the registry itself will vouch for the attacker's images. That is why this flaw scores 9.8 even though no exploitation has been reported yet — the impact is total for an affected registry, and the attack needs no account, no user interaction and only low complexity.

The supply-chain angle is the one to take seriously. This is the same class of problem as the GitHub CI secret-stealer attack, where stolen credentials reached into build pipelines: once an attacker can replace the images your pipeline pulls, the compromise flows downstream into every deployment. If your organisation runs Quay — or you use a hosted registry built on it — the question is not whether the flaw is theoretical, but whether your /keys endpoint is reachable by anyone you do not trust.

For Indian readers, the practical point is the same as anywhere else: Quay and OpenShift are widely used in enterprise and service-provider infrastructure in India, and many teams run registries that were set up years ago with anonymous access enabled for convenience. That single setting is what lets an unauthenticated attacker start this chain. The fix costs nothing — it is a network-access change, not a purchase.

What to do now: check, restrict, then patch

Red Hat's guidance is unusually specific, so follow it in this order:

Step	What to do	Why it matters
1. Restrict /keys	Block access to the /keys endpoint at your proxy or load balancer so only trusted internal Quay components can reach it.	This closes the attack path immediately, even before a fixed build exists.
2. Check the logs	Review audit logs for service_key_rotate and service_key_delete events with a null expiration_date.	A key with no expiry is the fingerprint of this attack.
3. Remove rogue keys	Delete any unrecognised approved service keys.	Removes the attacker's foothold — but remember it is not durable until a fixed build is deployed.
4. Fix CVE-2026-110697	Update Quay to 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 for your version.	Closes the cross-tenant robot-token leak, which already has fixed releases.
5. Watch for the 123710 fix	Track the Quay project releases; fixes were merged to GitHub on 11 November but no fixed released version was identified at the time of writing.	Deleting a rogue key alone is not durable — attackers can reinstall one until the fixed build is in place.

Do not rely on turning off anonymous access, changing passwords or rotating robot tokens — Red Hat says explicitly that none of those steps invalidates a rogue signing key. Similar auth-bypass patterns keep appearing across infrastructure software: the Xen Orchestra auth bypass disclosed this week also let unauthenticated attackers reach admin functions, and the PTC Windchill 9.2 RCE flaw patched this week is another reminder to treat critical infrastructure patches as same-day work.

✅ Should you care? Yes — if you run Red Hat Quay or rely on a registry built on it. Restrict the /keys endpoint today and check your audit logs for a key with no expiry date; that check takes minutes and tells you whether anyone has already been inside. If you do not run Quay at all, you can safely wait for the fixed release — but share this with the team that manages your registries.

FAQs

What is Red Hat Quay?
Red Hat Quay is an enterprise container registry — software that stores, manages and distributes container images, controlling who can download or upload the images used to build and deploy applications. It runs standalone, through the Quay Operator on OpenShift, or as the mirror registry for Red Hat OpenShift.

Is CVE-2026-123710 being exploited?
No exploitation in the wild had been reported as of 12 November 2026, and neither CVE-2026-123710 nor CVE-2026-110697 is in CISA's Known Exploited Vulnerabilities catalogue. That can change quickly now that the flaw is public and the fix is in the project's code, so the mitigation steps above should not wait for an exploitation report.

How do I fix CVE-2026-123710?
There is no fixed released version yet. Until one ships, restrict access to the /keys endpoint at your proxy or load balancer so only trusted internal components can reach it, review audit logs for service_key_rotate and service_key_delete events with a null expiration_date, and remove any unrecognised approved service keys. Fixes were merged into the Quay project's GitHub repository on 11 November, so watch for the next release and deploy it when it lands.

What is CVE-2026-110697 and is it related?
It is a second critical Quay flaw disclosed in the same batch: a 9.9 SQL injection in the robot-account listing that lets an authenticated attacker steal robot tokens from other tenants' namespaces. It is a different bug from CVE-2026-123710, but both were found by the same researcher and both target Quay's trust mechanisms — and unlike the 9.8 flaw, CVE-2026-110697 already has fixed releases (3.9.28 through 3.18.3, depending on your version).

Takeaway

A single weak check in Quay's key rotation lets anyone without an account install a signing key that never expires and forge tokens for every repository. Restrict the /keys endpoint now, check your logs for a key with no expiry, and patch both flaws as soon as the fixed builds land.

If your team runs Quay, check whether your /keys endpoint is reachable from outside your trusted network today — and if you want the wider pattern, read how the GitHub CI secret-stealer attack reached into build pipelines the same way.

Sources

Red Hat — CVE-2026-123710 advisory (primary source)
Red Hat — CVE-2026-110697 advisory (primary source)
NVD — CVE-2026-123710
SecurityWeek — Critical Red Hat Quay Vulnerability Could Expose Private Container Images (12 Nov 2026)
Red Hat Bugzilla — Report 2568072
Quay on GitHub — Fix pull request #8056
Threadlinqs — CVE-2026-123710 threat page