Red Hat Quay Fixes CVE-2026-123710 and CVE-2026-110697, Both Rated Critical by Red Hat, in Eight 3.x Branches; Red Hat Data Lists Quay 5 as Affected
Red Hat's CVE records score a Quay key-server flaw 9.8 and a robot-token leak 9.9 (CVSS 3.1). Fixes are in eight 3.x releases; none of the cited sources reports exploitation.
Editor's Note ·
- Clarification:
- The article says Red Hat's support article for CVE-2026-110697 'lists three effects rather than two' without saying which two it is compared with. The CVE record describes one effect (listing other tenants' robot accounts and their tokens); The Hacker News describes two (token theft, and robot accounts deleted when the attacker's namespace is deleted); Red Hat's support article lists three (listing tokens, deletion of the matching namespace's robot accounts, and a changed robot-account prefix when the underscore namespace is renamed).
- Clarification:
- The article says none of the cited pages explains why The Hacker News's 2026-11-12 description of Red Hat's CVE page for CVE-2026-123710 differs from the Herald's 2026-11-14 read. An Internet Archive capture of that Red Hat page taken on 2026-11-12 at 16:58 UTC lists 'Red Hat Quay 3' and 'Red Hat Quay 5' as Affected with no advisory, which matches The Hacker News; the page's per-branch Fixed entries for the eight advisories appear in the Herald's later read. The difference therefore reflects a change to Red Hat's page after that capture; the Herald did not establish when the page changed.
Overview
Red Hat made two flaws in its Quay container registry public on 2026-11-11 at 14:00 UTC, according to the CVE record for CVE-2026-123710 and the record for CVE-2026-110697, and has released fixed builds for eight Quay 3 branches, as reported by The Hacker News. Red Hat, which assigned both identifiers as the CVE Numbering Authority, gives CVE-2026-123710 a CVSS 3.1 base score of 9.8 (vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) and CVE-2026-110697 a score of 9.9 (vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H); both records also carry Red Hat’s own “Critical” severity rating (CVE-2026-123710, CVE-2026-110697). The National Vulnerability Database API returned HTTP 503 to the Herald on 2026-11-14 at 16:17 UTC, so no NVD score is reported.
Both records credit Dave O’Connor of Red Hat (CVE-2026-123710, CVE-2026-110697). None of the sources cited here names an outside reporter, and none reports exploitation of either flaw.
CVE-2026-123710: the service key flaw
The CVE record says an unauthenticated client can obtain an anonymous registry token with an audience it controls, present it to the service key rotation endpoint, and “install its own approved signing key with no expiry” (CVE record). Registry tokens signed with that key are then accepted for any repository, allowing read and write access to private images and replacement of repository tags (CVE record). Red Hat’s statement says key rotation “authenticates the caller only by verifying that the JWT is signed by an already approved service key with the expected audience and issuer, without checking that the token is a rotation credential” (Red Hat CVE page).
The same statement ends with the precondition: “Deployments where /keys is reachable by untrusted clients are affected” (Red Hat CVE page). A Red Hat support article says anonymous access is on by default and that, with it on, an attacker does not need an account, but adds that “Turning off anonymous access doesn’t protect you” because any valid Quay account can still exploit the flaw (Red Hat solution 7149923). The article also says resetting passwords or regenerating robot tokens does not revoke an unauthorized signing key, and it names standalone Quay, Quay deployed by the Quay Operator on OpenShift, and the mirror registry for Red Hat OpenShift as affected setups (Red Hat solution 7149923).
Red Hat’s mitigation is to restrict the /keys endpoint at the proxy or load balancer to trusted internal components, review audit logs for service_key_rotate and service_key_delete events with a null expiration_date, and remove unrecognised approved keys; it warns that deleting a rogue key “is not durable until a fixed build is deployed” because the anonymous request can install a new one (CVE record).
CVE-2026-110697: robot account tokens
This record describes a robot-account listing function that builds a SQL LIKE pattern from namespace names without escaping wildcard characters, so an attacker who creates a namespace containing an underscore can retrieve other tenants’ robot accounts and their decrypted tokens (CVE record). Red Hat’s statement says it “lets an authenticated attacker break tenant isolation in multi-tenant Quay deployments” (Red Hat security data), and the same statement says no elevated privileges or victim interaction are required (Red Hat security data). The 9.9 vector lists low privileges required and a changed scope (CVE record).
Red Hat’s support article for this flaw lists three effects rather than two: listing robot tokens, deletion of an underscore namespace also deleting the matching namespace’s robot accounts, and renaming an underscore namespace changing the prefix of the matching namespace’s robot accounts (Red Hat solution 7149592). The record says Red Hat has already fixed Quay.io and that there is “no other complete workaround” than updating (CVE record).
Fixed releases, and where the records differ
The CVE record lists eight fixed Quay versions (CVE record), and each is the version in the title of one Red Hat advisory. Both identifiers appear on every one of the eight advisory pages, which the Herald read on 2026-11-14 at about 16:20 UTC:
| Quay branch | Fixed version | Red Hat advisory |
|---|---|---|
| 3.9 | 3.9.28 | RHSA-2026:99021 |
| 3.10 | 3.10.28 | RHSA-2026:99025 |
| 3.12 | 3.12.24 | RHSA-2026:99027 |
| 3.14 | 3.14.10 | RHSA-2026:99024 |
| 3.15 | 3.15.9 | RHSA-2026:99023 |
| 3.16 | 3.16.7 | RHSA-2026:99022 |
| 3.17 | 3.17.7 | RHSA-2026:99026 |
| 3.18 | 3.18.3 | RHSA-2026:99019 |
Each page, for example RHSA-2026:99019, shows an issue date of 2026-11-11 and an update date of 2026-11-12, with no time zone, and lists other CVE identifiers as well.
On 2026-11-12, The Hacker News wrote that Red Hat’s CVE page for CVE-2026-123710 “still showed every Quay package as affected, with no fix”, and that none of the eight advisories listed CVE-2026-110697 (The Hacker News). The Herald’s read two days later differs: Red Hat’s CVE page and security data list the eight advisories as the fixes for CVE-2026-123710 (CVE page, security data), and its security data does so for CVE-2026-110697 as well (security data). The same data lists “Red Hat Quay 5” and “mirror registry for Red Hat OpenShift 2” with fix state “Affected” and no advisory under both identifiers (CVE-2026-123710, CVE-2026-110697). None of the cited pages explains the difference between the two reads or says when a fix for those two products is expected.
What the upstream project shows
The upstream repository’s commit “Fix CVE-2026-110697 and CVE-2026-123710 (#8056)” was committed on 2026-11-11 at 19:43 UTC, which the page data gives as 14:43 at UTC-05:00 (GitHub commit). In the Herald’s reading of that diff, it adds a check that a key-server token carries a key_rotation claim matching the key id, requires an expiry date in the future for keys added over HTTP, makes the registry token endpoint use the server’s hostname instead of the requested audience, and replaces the LIKE pattern built from the namespace name with a prefix_search helper (GitHub commit).
The upstream releases for seven of the eight branches were published on 2026-11-13 between 14:52:31 and 15:52:56 UTC (GitHub releases). The Herald’s own check, through GitHub’s contents API, found the KEY_ROTATION_CLAIM check in the key-server file at all seven of those tags, for example v3.18.3, and not at v3.18.2 or v3.9.27, for example v3.18.2. At 16:18 UTC on 2026-11-14 the upstream tag and release lists had no v3.15.9 (GitHub releases), although RHSA-2026:99023 is titled for Red Hat Quay 3.15.9. The seven release notes name neither CVE identifier (GitHub releases). The upstream release dates are two days after the advisories’ issue date (the Herald’s own subtraction), and no cited source says why.
Exploitation status
The CISA ADP Vulnrichment entry in the CVE record for CVE-2026-123710, timestamped 2026-11-13 at 14:17 UTC, records exploitation as none and automatable as yes (CVE record). The matching entry for CVE-2026-110697, timestamped 2026-11-12 at 16:00 UTC, records exploitation as none and automatable as no (CVE record). Neither identifier was in version 2026.11.13 of CISA’s Known Exploited Vulnerabilities catalog, released 2026-11-13 at 20:24 UTC and read by the Herald on 2026-11-14 (CISA KEV feed).