Red Hat has disclosed a critical vulnerability in Quay, its enterprise container registry, that lets an attacker with no valid account take over the service responsible for signing registry tokens. The flaw, tracked as CVE-2026-123710, carries a CVSS score of 9.8 and was published in Red Hat’s advisory and the National Vulnerability Database on November 11, 2026.

Quay stores and serves container images for organizations running their own registries, and its service key server is the component that issues and rotates the cryptographic keys used to sign access tokens. That server is supposed to check that any request to rotate a key is actually authorized to do so. According to Red Hat’s own bug report, it doesn’t.

How an Anonymous Token Becomes a Trusted Signing Key

The root cause is a validation gap. When a client asks the key server to rotate a signing key, the server verifies that the submitted JWT is signed by an already-approved key and that it carries the expected audience and issuer fields — but it never confirms that the token was actually issued for the purpose of key rotation. That distinction matters because, on deployments where the FEATURE_ANONYMOUS_ACCESS setting is enabled, an anonymous token obtained from the standard /v2/auth endpoint passes those checks anyway.

Worse, the audience field the server trusts is supplied directly by the client through a service parameter, meaning the attacker effectively controls the value the server is relying on to approve the request. Armed with that token, an attacker can submit their own key to Quay’s /keys endpoint. The new key inherits the approval status of whichever key signed the request, can be saved without an expiration date, and is trusted by Quay immediately.

From Signing Key to Full Registry Takeover

Once an attacker’s key is trusted, they can sign registry tokens valid against any repository in the deployment. That grants read and write access to private container images and the ability to overwrite repository tags. The consequences compound quickly:

• Private images frequently contain embedded secrets, credentials or proprietary code that a leak would expose well beyond the registry itself.
• Swapped tags are arguably more dangerous, since automated build and deployment pipelines may later pull a poisoned image without anyone noticing the substitution.
• The flaw has reportedly existed since Quay’s first public commit, meaning any long-running deployment with anonymous access enabled could have been exposed for years.

Red Hat notes that only deployments where the /keys endpoint is reachable by untrusted clients are actually at risk, and the issue affects both Quay 3 and Quay 5 image lines. Security researchers have drawn comparisons to a similar flaw previously found in the Gitea container registry, suggesting this class of signing-key validation bug may not be unique to Quay.

No Patch Yet — Here’s What Red Hat Recommends in the Meantime

As of publication, Red Hat’s advisory names no fixed release version. Until one ships, the company is urging administrators to treat this as urgent and take the following steps:

• Restrict access to the /keys endpoint at the proxy or load balancer level so only trusted internal components can reach it.
• Audit logs for service_key_rotate and service_key_delete events, paying particular attention to any entries with a null expiration date.
• Remove any approved service keys that administrators don’t recognize — though Red Hat cautions that deleting a rogue key alone won’t solve the problem, since an attacker with anonymous access can simply register a new one.

Red Hat credits its own researcher, Dave O’Connor, with discovering and reporting the issue. The company says it has seen no reports of active exploitation and no public proof-of-concept code has surfaced, but given that container registries sit at the center of most software delivery pipelines, the potential blast radius of a stolen signing key is substantial. Teams running Quay should prioritize the network-level mitigation now and keep a close watch on Red Hat’s advisory for the eventual patched release.