Critical Red Hat Quay Vulnerability Allows Unauthenticated Attackers to Hijack Container Registries

Blog WriterCybersecurity News - Original News Source is cybersecuritynews.com


A critical flaw in Red Hat Quay lets anyone who can reach a registry’s key server take over its token signing. The bug is tracked as CVE-2026-123710 and carries a CVSS score of 9.8, according to Red Hat’s advisory and the National Vulnerability Database. Red Hat published it on November 11, 2026.

Quay is an enterprise container registry that stores and serves images. The weakness sits in its service key server. When a caller asks to rotate a signing key, the server only checks that the JWT is signed by an approved key and has the right audience and issuer. It never checks whether the token was meant for key rotation.

Red Hat Quay Vulnerability

An anonymous token from the /v2/auth endpoint passes that check. Red Hat’s Bugzilla report says the audience comes straight from a client-supplied service parameter, so the attacker controls it. This applies when FEATURE_ANONYMOUS_ACCESS is on.

With that token, the attacker sends their own key to the /keys endpoint. The new key copies the approval of the key that signed the request and can be saved with no expiry date. Quay then trusts it right away.

From there, the attacker can sign registry tokens that work on any repository. That gives read and write access to private images and lets them swap repository tags. Private images often hold secrets, so a leak can reach well beyond the registry.

Replaced tags are just as risky, because build systems may pull the poisoned image later. The same pattern has hit other registries, such as the Gitea container registry flaw that exposed private images.

Red Hat lists Quay 3 and Quay 5 images as affected, and the NVD entry shows the same products. Only deployments where /keys is reachable by untrusted clients are exposed. The Bugzilla note says the logic has been present since the first public commit.

Red Hat’s first step is to limit /keys at the proxy or load balancer so only trusted internal components can reach it. Next, check audit logs for service_key_rotate and service_key_delete events with a null expiration_date. Remove any approved service keys you don’t recognize.

Deleting a rogue key will not fix the problem for long. The anonymous request can simply install a new one until a fixed build is running. Teams should keep the /keys block in place and watch Red Hat’s advisory for a patched release. The advisory names no fixed version yet.

Registries sit at the center of software delivery, so a stolen signing key puts every image at risk. Teams that rely on Quay can also read our guide to the best container registry security tools for more ideas on protection.

Red Hat credits its own researcher, Dave O’Connor, with finding the bug. Nobody has reported attacks in the wild, and one tracker notes that no public exploit code has been indexed. Still, the steps are simple, and the damage is large, so treat this as urgent.

Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.

The post Critical Red Hat Quay Vulnerability Allows Unauthenticated Attackers to Hijack Container Registries appeared first on Cyber Security News.