Red Hat Quay CVE-2026-123710: Critical Registry Risk
Краткое содержание
Pixel shares details on critical Red Hat Quay vulnerability CVE-2026-123710, rated 9.8, which may let unauthenticated attackers add trusted signing keys, access private images, and overwrite tags. The announcement outlines affected Quay deployments, patching guidance, and mitigations to help protect registries and systems that pull their images.
DEV Community
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 SQ...

Powered by Readybot.io