Red Hat has disclosed two vulnerabilities in Red Hat Quay, its container image registry, rating both "Critical," its highest severity level. The flaws, CVE-2026-123710 and CVE-2026-110697, are described on the company's security pages and carry CVSS 3.1 base scores of 9.8 and 9.9. If exploited, they could let attackers read and write private images in a registry or steal the robot account credentials of other users. Red Hat says it found both issues itself.
Both Flaws Score 9.8 or Higher and Are Rated Critical
Here is a summary of the two vulnerabilities listed on Red Hat's security pages.
| CVE | CVSS 3.1 | Issue |
|---|---|---|
| CVE-2026-123710 | 9.8 | Abuse of the service key mechanism lets an attacker register their own signing key |
| CVE-2026-110697 | 9.9 | Robot account listing can return other tenants' accounts and tokens |
Details are available on Red Hat's CVE-2026-123710 page and CVE-2026-110697 page.
Unauthenticated Attackers Can Register Their Own Signing Key (CVE-2026-123710)
According to Red Hat, CVE-2026-123710 allows even an unauthenticated client to obtain an anonymous registry token (issued by /v2/auth) and present it to the service key rotation endpoint (/keys), installing a signing key of its own with no expiry. Tokens signed with that key are accepted for any repository, enabling reads and writes of private images and replacement of tags.
The root cause is that the key rotation process checks only whether a token is signed by an already-approved key and carries the expected issuer and audience. It does not check whether the token is actually a credential meant for key rotation. Red Hat says deployments where untrusted clients can reach /keys are affected.
Other Tenants' Robot Account Tokens Can Leak (CVE-2026-110697)
CVE-2026-110697 is a flaw in how Quay lists robot accounts, which are accounts used for automation. When building a SQL LIKE pattern from namespace names, Quay did not escape characters that act as wildcards. As a result, an attacker who creates a namespace containing an underscore can match other tenants' namespaces and retrieve their robot accounts along with decrypted tokens.
Red Hat explains that the flaw breaks tenant isolation in multi-tenant Quay deployments and requires no elevated privileges or action by the victim. It also notes that in OpenShift environments, stolen robot account credentials could be used to inject images into CI/CD pipelines.
Updating to Fixed Releases and Restricting Access to /keys Are Required
For CVE-2026-110697, Red Hat lists the following fixed releases: 3.9.28, 3.10.28, 3.12.24, 3.14.10, 3.15.9, 3.16.7, 3.17.7, and 3.18.3. The company says Quay.io, the service it operates, has already been fixed. There is no complete workaround other than updating. For those who cannot update right away, Red Hat suggests restricting who can create organizations or namespaces containing an underscore, rotating robot tokens for namespaces whose names collide, and monitoring registry activity, but says these steps do not fix the underlying flaw.
For CVE-2026-123710, the page does not list fixed version numbers, but says an update to a fixed build is needed. In the meantime, Red Hat recommends using a proxy or load balancer to limit access to /keys to trusted internal components, and reviewing audit logs for service_key_rotate and service_key_delete events with an empty expiration date, removing any approved service keys that are not recognized. It cautions, however, that deleting a rogue key does not last until a fixed build is deployed, because an anonymous request can register a new key again.
Our Take
A container registry is where images flow from development to production, so allowing unauthorized writes or tag replacement there can affect every environment that pulls from it. Both of these flaws stem from basic mistakes, a missing authorization check and an unescaped input, yet their impact extends to the entire registry and across tenant boundaries. Organizations that run Quay themselves should prioritize applying fixed releases, and before and after updating, confirm that /keys is not reachable from outside and that the audit logs show no suspicious key registrations.
Summary
Red Hat has disclosed two Critical vulnerabilities in Red Hat Quay. One could let attackers register a signing key without authentication and read and write private images, while the other could expose other tenants' robot account tokens. Quay administrators should update to the fixed releases and review the interim mitigations Red Hat has published.
