Red Hat published fixes for two critical Quay flaws yesterday, and the first one is about as bad as a container registry bug gets.

CVE-2026-123710 lets an attacker who can reach a Quay registry read and overwrite private container images in every repository. Not one repository. Every repository.

The CVSS score is 9.8. Fixed builds are out for eight Quay 3 branches.

Why Anonymous Access Is Not the Protection You Think

Quay enables anonymous access by default, and while it is on, the attacker needs no account at all.

Turn it off and the flaw is still there. Anyone with a valid account can exploit it.

Red Hat's remediation article states it plainly. Turning off anonymous access does not protect you. A planted key also keeps working after password resets and after robot token changes.

How the Key Injection Works

Quay signs access tokens with keys it trusts. Those tokens are what allow image pushes and pulls.

The flaw lets an attacker add their own key to that trusted set, with no expiry date. Quay then accepts tokens signed with that key for any repository.

From there, the damage is direct.

That third item is the quiet one. It is not data theft, it is sabotage, and it is available from the same foothold.

The planted key survives restarts until someone removes it.

The Missing Check

The root cause is a validation gap in Quay's key server.

The key server checks that a request to replace a key carries a token signed by a trusted key, with the expected audience and issuer. It does not check whether the token was issued for key rotation.

An anonymous token from Quay's /v2/auth endpoint passes the check. Quay signs it with a trusted key, and the caller chooses its audience. That is the whole bypass.

According to the bug report, this logic has been in Quay since its first public commit.

The Second Flaw: Robot Token Theft

CVE-2026-110697 scores 9.9 and is a different class of problem.

It lets a Quay user who can create a namespace steal other tenants' robot account tokens, then use them to read, push, or overwrite those tenants' images.

The mechanism is an escaping failure in SQL. The code that lists robot accounts builds a LIKE pattern from the namespace name without escaping wildcard characters. 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.

No elevated privileges needed. Nothing the victim has to do.

The Collateral Damage

Deleting the attacker's namespace also deletes the corresponding robot accounts, which can cut off systems that depend on them.

And there is a supply chain angle. Where Quay is the integrated registry for OpenShift, stolen robot credentials can be used to inject malicious images into CI/CD pipelines.

That is the escalation path worth tracking. A stolen robot token is not just read access to an image. It is a route into the build process.

What Red Hat Says Is Affected

Red Hat lists every version of Quay 3 and Quay 5 as affected by both flaws.

For CVE-2026-123710, the guidance names standalone installs, Quay deployed by the Quay Operator on OpenShift, and the mirror registry for Red Hat OpenShift.

The scope statement that matters most is this one. Any Quay instance that untrusted clients can reach is exposed, including internal registries.

Internal is not a security boundary here.

The Documentation Contradictions

Two inconsistencies in Red Hat's own materials are worth flagging, because they affect how you verify a fix.

CVE-2026-123710. When checked, the CVE entry still showed every Quay package as affected, with no fix listed, even though each of the eight advisories names the flaw.

CVE-2026-110697. The CVE page names the same eight releases as fixed and calls updating the only complete fix. Quay.io is already fixed. But none of the eight advisories list CVE-2026-110697.

So the CVE database and the advisories disagree in opposite directions on the two flaws. Verify by the version you are actually running, not by the tracker page.

The Interim Mitigation

Red Hat's guidance for CVE-2026-123710 is specific and actionable.

• Block the /keys endpoint at the proxy or load balancer, for everything except trusted internal components.
• Search audit logs for service_key_rotate and service_key_delete events where expiration_date is null.
• Remove any approved service keys you do not recognize.
• Install the fixed release.

That last point carries a warning. Until the fixed release is running, an attacker can add a new key the same way. Deleting a planted key does not last unless the code is patched.

For CVE-2026-110697, the interim steps are less complete. Red Hat suggests limiting who can create organizations or namespaces containing an underscore, rotating robot tokens for any namespace that matches an underscore namespace, and watching for pulls or pushes that do not fit normal robot usage.

These steps reduce exposure. The flaw remains.

What the Upstream Fix Changes

The upstream fix does three things, and together they close the mechanism rather than the symptom.

• Adds the missing rotation check
• Requires keys added through the key server to have an expiry date
• Stops callers from choosing a token's audience

The same change also fixes the robot account search.

What Administrators Should Do

• Patch every Quay instance. Standalone, Operator-managed, and the OpenShift mirror registry. Eight branches have fixes.
• Block /keys now, even if you cannot patch today. That is the single control that stops new keys from being planted.
• Audit for planted keys before you patch. Look for service_key_rotate and service_key_delete events with a null expiration_date in your audit logs. Remove anything you do not recognize.
• Do not rely on authentication settings. Anonymous access off, password rotated, robot token changed. None of it removes a key that is already planted.
• Check for underscore namespaces. For CVE-2026-110697, review namespaces containing underscores and rotate the robot tokens in any namespace that could have been matched.
• Watch robot account behavior. Pushes or pulls that do not fit a robot's normal pattern are the detection signal for token theft.
• Treat any Quay instance reachable by untrusted clients as exposed, internal registries included.
• Verify the fix by version, not by the CVE tracker. The CVE entries and the advisories disagree on both flaws.

The Structural Problem

A container registry is a trust anchor. Every deployed container on every cluster traces back to one.

That is why both of these flaws matter more than their CVSS scores already suggest. CVE-2026-123710 is not "read some images." It is "write to the artifact that every downstream system will pull and run."

CVE-2026-110697 is not "steal a token." It is "get into the CI/CD pipeline that produces the artifacts."

Neither one requires an attacker to compromise a cluster. They only require reaching the thing the cluster trusts.

FAQ

What is CVE-2026-123710?

A critical (9.8) flaw in Red Hat Quay that lets an attacker add their own signing key to Quay's trusted keys, with no expiry. Quay then accepts tokens signed with that key for any repository, allowing private image reads and overwrites.

Does anonymous access need to be enabled?

No. Quay enables anonymous access by default, and the attacker needs no account while it is on. With anonymous access off, anyone with a valid account can still exploit it.

Why doesn't a password reset or robot token change help?

Because the planted key is separate from those credentials. Red Hat states that a planted key continues to work after password resets and robot token changes.

What is CVE-2026-110697?

A critical (9.9) flaw that lets a user who can create a namespace steal other tenants' robot account tokens, then use them to read, push, or overwrite those tenants' images.

How does the robot token theft work?

The code that lists robot accounts builds a SQL LIKE pattern from the namespace name without escaping wildcards. Since _ matches any single character in SQL LIKE, a namespace with an underscore can match another tenant's namespace.

Which Quay versions are affected?

Every version of Quay 3 and Quay 5, according to Red Hat.

What are the interim mitigations?

Block /keys at the proxy or load balancer for everything except trusted internal components. Audit for service_key_rotate and service_key_delete events with a null expiration_date. Remove unrecognized approved service keys. Then patch.

Why is patching required after deleting a key?

Because until the fixed release is running, an attacker can plant a new key the same way.

Do the CVE records agree with the advisories?

No. The CVE entry for CVE-2026-123710 still showed every package as affected with no fix, despite the advisories naming it. The CVE page for CVE-2026-110697 says the eight releases are fixed, but none of the eight advisories list that CVE. Verify by version.

Is Quay.io affected?

Red Hat says Quay.io is already fixed.

Who found the flaws?

Dave O'Connor of Red Hat found both.

Source: The Hacker News