CVE-2026-123710 (CVSS score: 9.8) lets an attacker who can reach a Red Hat Quay registry read and overwrite every private container image — without expiry on the key they install.
How CVE-2026-123710 abuses Quay's trusted keys
Quay uses keys it trusts to sign the access tokens that permit image pushes and pulls. The vulnerability allows an attacker to add their own key to Quay's trusted key set with no expiration date. Once the key is approved, Quay accepts tokens signed with that key for any repository. With those tokens, an attacker can retrieve private images and any secrets or credentials contained inside them, or push and overwrite images so that the malicious change propagates to every system that later pulls those images.
The planted key survives restarts until someone removes it, and an attacker can use the planted key to delete the keys that running Quay instances use, causing normal pushes and pulls to fail with authentication errors. The root cause is that Quay's key server checks that a request to replace a key carries a token signed by a trusted key, with the expected audience and issuer, but it does not verify that the token was issued specifically for key rotation. An anonymous token returned by Quay's /v2/auth endpoint passes that test because Quay signs it with a trusted key and the caller can choose the audience.
How CVE-2026-110697 exposes robot account tokens
The second critical flaw, CVE-2026-110697 (CVSS score: 9.9), lets a Quay user who can create a namespace steal other tenants' robot account tokens and use them to read, push, or overwrite those tenants' images. The bug lies in code that lists robot accounts: it builds an SQL LIKE pattern from the namespace name without escaping wildcard characters. In SQL LIKE, an underscore matches any single character, so a namespace created with an underscore in the right position can match another tenant's namespace and return that tenant's robot accounts, including their decrypted tokens. The attacker needs no elevated privileges, and the victim does not have to take any action.
Deleting the attacker's namespace also deletes the corresponding robot accounts, which can cut off systems that rely on them. Where Quay is the integrated registry for OpenShift, Red Hat says stolen robot credentials can be used to inject malicious images into CI/CD pipelines.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleWhich Quay installations are affected
Red Hat lists every version of Quay 3 and Quay 5 as affected by both flaws. For CVE-2026-123710, its guidance names standalone installs, Quay deployed by the Quay Operator on OpenShift, and the mirror registry for Red Hat OpenShift as affected. The company warns that any Quay instance that untrusted clients can reach is exposed, including internal registries. Quay enables anonymous access by default, and while anonymous access is enabled an attacker needs no account; when it is off, anyone with a valid account can still exploit the flaw.
Red Hat has released fixed builds for eight Quay 3 branches. The company's CVE page says updating is the only complete fix for CVE-2026-110697 and notes that Quay.io is already fixed. However, when checked today the CVE entry for CVE-2026-123710 still showed every Quay package as affected, with no fix listed, even though each advisory lists the flaw.
Red Hat's mitigations and the upstream code changes
Red Hat's recommended immediate actions include:
- At the proxy or load balancer, block the /keys endpoint 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; until it is running, an attacker can add a new key the same way, so deleting one does not last.
The company's key remediation article warns, "Turning off anonymous access doesn't protect you." A planted key continues to work after password resets and changes to the robot token. For CVE-2026-110697 the company additionally 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 use. Those steps reduce exposure but do not eliminate the flaw until an update is installed.
The upstream code changes add the missing rotation check, require keys added through the key server to have an expiry date, and stop callers from choosing a token's audience. Red Hat says the same change fixes the robot account search problem too.
What this means for OpenShift operators, registry administrators, and CI/CD teams
OpenShift operators and administrators of Quay-deployed registries should treat every exposed Quay instance as at immediate risk, because the company explicitly names Quay Operator deployments and the mirror registry for Red Hat OpenShift as affected. Registry administrators need to check for unexpected approved service keys with null expiration dates in audit logs, block /keys at the edge, and prioritize installing the fixed builds Red Hat published for the eight Quay 3 branches.
CI/CD teams and any systems relying on robot accounts must rotate robot tokens for namespaces that could be matched by underscore-containing names and monitor for unusual pulls or pushes. Because stolen robot credentials can be used to inject malicious images into pipelines, teams should validate images and consider additional integrity controls until fixes are universally deployed.
Red Hat credits Dave O'Connor with finding both flaws and notes that the logic behind CVE-2026-123710 has been present since Quay's first public commit, according to the bug report. The immediate path to remediation is technical: block the key endpoint where feasible, hunt for and remove unexpected keys, and deploy the vendor's fixed releases.
