One Planted Key. Every Private Image Was Open.

A container registry is where a company keeps the images every server, laptop and cloud workload is built from. Red Hat Quay is one of the registries enterprises trust with exactly that — and this week Red Hat disclosed two critical flaws that, together, let an attacker read and overwrite private images across an entire registry. The worse of the two needs no account, no password and no insider access. It needs a key the attacker plants themselves.

Both flaws were found by Red Hat’s own Dave O’Connor, and both are now patched. But every version of Quay 3 and Quay 5 is affected, the worst flaw’s logic has been in the product since its first public commit, and any registry untrusted clients can reach — including internal ones — is exposed until the fixed build lands.

A key Quay was never supposed to accept

The first flaw, CVE-2026-123710, carries a CVSS score of 9.8. Quay decides who may push and pull images using access tokens, and it signs those tokens with keys it trusts. The flaw lets an attacker add their own key to that trusted set — with no expiry date. From that moment, Quay accepts tokens signed with the attacker’s key for any repository on the registry.

The way in is almost embarrassingly simple. Quay’s key server checks that a key-replacement request carries a token signed by a trusted key, with the expected audience and issuer. What it never checked was whether the token had been issued for key rotation. An anonymous token from Quay’s own /v2/auth endpoint passes every check — Quay signs it with a trusted key, and the caller chooses its audience. Since Quay enables anonymous access by default, the attacker needs no account at all; turn it off, and anyone with any valid account can still walk in. “Turning off anonymous access doesn’t protect you,” Red Hat says.

A planted key is durable: it survives restarts, password resets and robot-token changes. With tokens it signs, an attacker can pull private images — and any secrets baked into them — or overwrite images, so the tampered version propagates to every system that pulls it later. The key can also delete the keys running Quay instances rely on, breaking normal pushes and pulls.

The underscore that stole other tenants’ robots

The second flaw, CVE-2026-110697, scores even higher at 9.9 — and it is a different kind of mistake. Quay’s robot accounts are the machine credentials that CI/CD pipelines use to push and pull images. The code that lists robot accounts builds an SQL LIKE pattern from a namespace name without escaping wildcard characters. In SQL LIKE, an underscore matches any single character.

So a user who creates a namespace with an underscore in the right place can match another tenant’s namespace and receive its robot accounts — with their decrypted tokens. No elevated privileges are needed, and the victim does nothing. Those tokens can read, push or overwrite the victim’s images; where Quay is OpenShift’s integrated registry, Red Hat warns, they can inject malicious images straight into CI/CD pipelines. Deleting the attacker’s namespace even deletes the robot accounts, cutting off systems that depend on them.

Every version is affected — and the records disagree

Red Hat lists every version of Quay 3 and Quay 5 as affected by both flaws. For the key flaw, its guidance names standalone installations, Quay deployed by the Quay Operator on OpenShift, and the mirror registry for Red Hat OpenShift. Fixed builds are out for eight Quay 3 branches, and Quay.io, Red Hat’s hosted registry, is already fixed.

One wrinkle: the public records contradict each other in opposite directions. The CVE entry for the key flaw still showed every package as affected, with no fix listed, even though each advisory names it. For the robot-token flaw, the CVE page names the same eight releases as fixed — yet no advisory lists that CVE. Verify by the version you actually run, not by the tracker page.

What to do now

Red Hat’s recommended sequence starts at the edge: at your proxy or load balancer, block the /keys endpoint for everything except trusted internal components. Next, search your audit logs for service_key_rotate and service_key_delete events where the expiration date is null, and remove any approved service keys you do not recognize. Then install the fixed release — until it is running, an attacker can simply plant a new key the same way, so deleting one does not last.

For the robot-token flaw, updating is the only complete fix. Until then, Red Hat suggests limiting who can create organizations or namespaces containing an underscore, rotating robot tokens for any namespace that an underscore namespace could match, and watching for pulls or pushes that do not fit normal robot use. The upstream fix closes both holes at once: it adds the missing rotation check, requires keys added through the key server to carry an expiry date, stops callers from choosing a token’s audience, and fixes the robot account search.

Registry flaws are supply-chain flaws: whoever controls the images controls what every downstream system runs. We have seen the same pattern in the critical Linux kernel flaw Red Hat patched earlier this month and in the four perfect-score SAP flaws disclosed the same week — the fix exists, and the race is whether it lands before someone walks through the open door.