Critical Red Hat Quay Flaw: Attackers Can Read and Overwrite Your Containers

What happened

On November 11, 2026, Red Hat published two critical security advisories for Red Hat Quay — the enterprise container registry that organizations use to store, manage, and distribute images across development and production. Both vulnerabilities let an attacker gain access to other teams' private images, or even replace them.

The first — CVE-2026-123710, rated CVSS 9.8 — lets an unauthenticated attacker take over registry token signing: in effect, obtain the "master key" that signs every read and write permission. The second — CVE-2026-110697, rated CVSS 9.9 — lets a user who can create a namespace steal other tenants' robot-account tokens.

What the two have in common: after exploitation, an attacker can read private images along with any secrets and credentials stored inside them, and can also overwrite images — and a replaced image propagates to every system that later pulls it. In short, a ready-made software supply-chain attack scenario.

What Red Hat Quay is, and why signing keys are everything

Red Hat Quay is a private container registry, usually deployed either as a standalone service (via Podman or Docker), through the Quay Operator on OpenShift, or as a mirror registry for OpenShift. Many teams store closed application images in it, and the registry decides who can pull and push images.

Quay's authorization mechanism is built on tokens. When a client requests access, the /v2/auth service issues a signed token (JWT) that the registry then accepts for a specific repository. These tokens are signed by a set of "service keys" that Quay treats as trusted. Whoever holds a trusted key can mint their own tokens for any repository.

That is exactly the mechanism that was broken. The key detail: when Quay rotates keys through the /keys endpoint, it checks that the request is signed by an already-trusted key with the expected audience and issuer. But it does not check whether that token was actually issued for key rotation. An anonymous token that anyone can obtain for free at /v2/auth passes this check — it is signed by a trusted key, and the caller chooses the audience themselves.

Technical details of the attack

The attack consists of a few simple steps. First, the attacker obtains an anonymous registry token at /v2/auth. Then they present that token to the key-rotation endpoint /keys — and install their own signing key, which Quay automatically marks as trusted. The key can be created with no expiration date: it lives forever.

The consequences for the registry owner are severe:

• The attacker can pull private images from any repository — including images belonging to other organizations — along with secrets, API keys, or credentials that developers mistakenly hard-coded inside them.
• They can push or overwrite images. A replaced image propagates to every system that later pulls it — a classic software supply-chain attack vector.
• They keep access indefinitely: the installed key has no expiry and survives registry restarts until someone removes it manually.
• They can delete the legitimate keys a running registry uses — after which normal pushes and pulls start failing with "authentication required" or "unauthorized" errors, even when users' credentials are unchanged.

Red Hat specifically highlights two insidious points. First, anonymous access in Quay is enabled by default (the FEATURE_ANONYMOUS_ACCESS=True flag in Quay 3.18.2) — so the attacker does not even need an account. Second, turning off anonymous access does not help: any valid Quay account can still exploit the flaw. Password resets and robot-token regeneration also do not revoke an installed malicious key.

The logic behind this flaw has been present in Quay since its first public commit, according to Red Hat's Bugzilla report — meaning this is not a new mistake, but a long-standing weakness that has only now been discovered.

The second critical flaw: CVE-2026-110697

At the same time, Red Hat disclosed another critical flaw — CVE-2026-110697, rated CVSS 9.9. It affects multi-tenant Quay deployments and lets a user who can create a namespace steal other tenants' robot-account tokens.

The technical cause is a classic SQL LIKE mistake. The code that lists robot accounts builds a LIKE pattern from the namespace name without escaping wildcard characters, and in SQL LIKE an underscore (_) matches any single character. So a namespace with an underscore in the right position can match another tenant's namespace — and return its robot accounts with their decrypted tokens.

The attacker needs no elevated privileges, and the victim does not have to do anything. A side effect: deleting the attacker's namespace also deletes the corresponding robot accounts, which can cut off systems that rely on them. Red Hat specifically notes that where Quay is the integrated registry for OpenShift, stolen robot credentials can be used to inject malicious images into CI/CD pipelines.

Who is affected

Both flaws affect, according to Red Hat, every version of Quay 3 and Quay 5. The company's documentation names the following affected configurations:

• standalone Quay deployments (Podman or Docker);
• Quay deployed via the Quay Operator on OpenShift;
• the mirror registry for Red Hat OpenShift.

What is more, not only public registries are vulnerable, but also internal ones: any Quay instance reachable by untrusted clients — including those "hidden" inside the network. This matters: teams often treat an internal registry as safe by default, yet here it is exactly the primary target.

Red Hat has already fixed the hosted Quay.io service. Self-hosted installations, however, require a manual update. Red Hat released fixed builds for eight Quay 3 branches: 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. For those building Quay from source (Project Quay), the fix is in commit 094cfb024f01 — but the newest tag v3.18.2 does not yet contain it, so "just take the latest release" is not enough.

Both flaws were found by Red Hat researcher Dave O'Connor. The timeline is telling: Red Hat filed the first bug (CVE-2026-110697, the LIKE injection) on October 14, 2026, the second (CVE-2026-123710, unauthenticated key rotation) on November 6, and on November 11 both CVE records were published and the fix was merged into the repository. In other words, 28 days passed from the first report to the fix.

How to defend: Red Hat's steps

Red Hat proposes four steps — and they should be executed in the right order, because until the fix is installed none of the first three provides lasting protection:

1. Block the /keys endpoint at the proxy or load balancer so that only trusted internal components can reach it.
2. Review the audit logs for service_key_rotate and service_key_delete events where the expiration_date field is null. This indicates an installed malicious key.
3. Remove any approved service keys you do not recognize.
4. Install the fixed build for your branch.

Why the order matters: until the fix is deployed, the attacker can add a new key the same way — so removing the malicious key without updating provides only a temporary effect. Red Hat stresses: "turning off anonymous access does not protect you," and an installed malicious key keeps working after password resets and robot-token changes.

Why this is a lesson for everyone working with containers

This incident is not just about Red Hat. It is about the fact that a container registry is a critical node in the software supply chain, and compromising that node gives an attacker far more than breaching a single application: they gain a point from which malicious code can be spread to every system that pulls images.

A few practical takeaways for DevOps and security teams. First, do not keep secrets inside images; use external secret stores, because "hard-coded" credentials are exactly what makes an image leak especially painful. Second, treat an internal registry as a resource potentially reachable by an attacker: restrict network access and watch the logs. Third, regularly reconcile your container-image inventory against sources and check whether your systems are present in known credential leaks — for example with our breach check tool.

Conclusion

Two critical vulnerabilities in Red Hat Quay are a reminder that even mature infrastructure products can harbor flaws for years that completely break their security model. CVE-2026-123710 is especially instructive: a mistake in validating one type of token turns an anonymous visitor into the holder of the "master key" for the entire registry.

If your team runs a self-hosted Red Hat Quay (or Project Quay), do not delay: check your version, follow Red Hat's four steps, and update to a fixed build. And to understand how to protect container environments and supply chains systematically, it is worth building up expertise — for example through cybersecurity courses or specialized industry events where practitioners unpack these topics.