Red Hat Published Eight Fixed Quay Releases Within Two Hours of Its CVSS 9.8 Signing-Key Advisory, but the CVE Page Still Lists No Fix, and the Sibling 9.9 Flaw’s Page Names Those Releases While None of Their Advisories Lists It

Red Hat published fixed versions of Red Hat Quay, its enterprise container registry, within two hours of disclosing CVE-2026-123710, a critical flaw (CVSS 9.8) that lets a client take over the registry’s token signing. Between 15:34 and 15:41 UTC on November 11 it put Quay 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 into its container catalog, each under its own Critical advisory, and each advisory lists the CVE. SecurityWeek reported on November 12 that “Neither the advisory nor the Bugzilla report identifies a fixed version.” That is accurate for those two documents. The fixed versions are in a third place, the errata.

The records do not line up, though. At 10:37 UTC on November 12, about 19 hours after the images appeared, Red Hat’s CVE page still listed Quay 3 and Quay 5 as “Affected,” with nothing in its Errata or Release date columns. The page for the sibling flaw, CVE-2026-110697 (CVSS 9.9), names the same eight releases as the fix, yet none of the eight advisories lists that CVE. And the open-source repository on GitHub, where the change for the first flaw has been on every Quay 3 release branch since November 6, has no tag for any of the eight releases.

Nothing we read says either flaw has been used in an attack. Neither is in CISA’s Known Exploited Vulnerabilities catalog (version 2026.11.10, the newest at our check), FIRST’s EPSS service has no score for either, SecurityWeek reports no attacks, and NVD has not yet analyzed either record. The practical answer for a Quay 3 operator is short: apply the advisory for your stream, then check the registry for a signing key that was installed before the update, because nothing in the patch removes one. Operators of Quay 5, or of builds from the open-source branches, have no tagged release to apply yet.

Two critical flaws, fixed in one pull request

Red Hat disclosed both flaws on November 11 and credits both to one of its own engineers. SecurityWeek covered the first and mentioned the second in a sentence, so the table sets them side by side. Robot accounts, named in the right-hand column, are the non-human accounts that build pipelines use to push and pull images.

Red Hat’s statement for CVE-2026-123710 says: “This Critical flaw in Red Hat Quay’s service key server allows an unauthenticated attacker to take over registry token signing.” The key server is the part of Quay that stores and serves the public keys the registry checks its tokens against. In Red Hat’s words, “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. An anonymous token minted by /v2/auth satisfies that check.” The CVE text finishes the chain: the client can “install its own approved signing key with no expiry,” and registry tokens signed with that key are accepted for any repository, which allows read and write access to private images and replacement of repository tags. Red Hat’s Bugzilla report adds that rotation “also deletes the legitimate instance key as a side effect, and the attacker key can delete replacement instance keys,” so an attacker can also break legitimate pushes and pulls.

The second flaw is a different kind of bug. Red Hat says the robot-account listing function “constructs a SQL LIKE pattern from user-controlled namespace names without escaping wildcard metacharacters,” so an attacker who creates a namespace containing an underscore character can match robot accounts, and retrieve their decrypted tokens, in other tenants’ namespaces. Red Hat’s record says it lets “an authenticated attacker break tenant isolation in multi-tenant Quay deployments.”

Eight fixed releases, one advisory each

Red Hat’s container catalog lists each Quay image with the advisory it shipped under, and each advisory page lists the CVEs and bugs it fixes. We read both for every Quay 3 release pushed on November 11:

All eight advisories are named for their release, are rated Critical and were issued on November 11. Each lists CVE-2026-123710 and its Bugzilla bug, 2568072. None lists CVE-2026-110697 or its bug, 2552237. Each image was published for several processor architectures, with the first and last of a release a few seconds apart. The other CVEs in these advisories are mostly bundled libraries: for 3.18.3, the titles of the Bugzilla bugs it cites show flaws in msgpack, pyasn1, Pillow, oauthlib and xhtml2pdf alongside Quay’s own.

Two limits apply. We could not open the images: the catalog repository on registry.access.redhat.com answers that it “requires terms acceptance and is only available on registry.redhat.io,” so the claim that these builds carry the fix rests on the advisories and on the branch history below, not on reading the code inside them. And Red Hat’s release notes for Quay 3.18 sit on docs.redhat.com, which refused our scripted requests, so we did not read what they say about either CVE.

Where Red Hat’s records disagree

The machine-readable side is missing as well. At 10:39 UTC the per-advisory CSAF file returned HTTP 404 for all eight Quay advisories, while the neighboring RHSA-2026:99020, issued at 17:42 UTC on November 11, has one, and Red Hat’s CSAF listing by CVE returned an empty list for both CVEs. That fits the empty Errata columns on the CVE pages (our reading), but it does not explain why the page for the second flaw names the releases while the advisories do not list that flaw.

We cannot tell from the public records whether the new builds carry the fix for CVE-2026-110697 as well. The branch history below says its change was on every release branch three weeks before the images were built, and the CVE page names these builds, so we expect they do, but no advisory says so. For operators the consequence is practical: a scanner fed by Red Hat’s CVE data may keep flagging the fixed releases as vulnerable until those records are updated, so confirm a fix from the advisory page, not the CVE page (our reading).

The fixes were on the public release branches before the advisory

By our arithmetic, the change for CVE-2026-123710 reached the eight release branches between 4 days 19 hours 15 minutes and 4 days 19 hours 42 minutes before Red Hat’s 14:00 UTC advisory time, under a message that names no CVE. The change for CVE-2026-110697 reached them about 22 days before, under messages that name the CVE ID. Both are ordinary commits in a public repository, so anyone watching those branches could have seen them (our reading). We did not look for evidence that anyone did, and the sources do not say whether the timing was planned.

The code the fix changes is old. The history of endpoints/keyserver/__init__.py on redhat-3.18 has four commits: the November 2019 open-source import, a December 2019 formatting commit, an August 2023 cleanup and the November 2026 fix. Red Hat’s Bugzilla report says: “The logic is present from the first public commit.”

On GitHub’s side, the last two releases were published 3 hours 11 minutes (3.17.6) and 6 hours 25 minutes (3.18.2) after Red Hat’s image appeared in the catalog (our arithmetic from the catalog and GitHub’s releases API). For the eight new releases the repository still had no tag at 10:37 UTC, so anyone who tracks GitHub tags rather than Red Hat’s catalog sees only v3.18.2 and older, and the newest tag of each of the eight streams (v3.9.27 to v3.18.2) contains neither fix.

What the patch changes

Pull request 8056 changes 11 files, and the key server part of it is the same on every Quay 3 release branch. Our reading of the diff in endpoints/keyserver/__init__.py, endpoints/v2/v2auth.py and data/model/service_keys.py:

• Token audience. The registry’s token endpoint now sets a token’s audience to the server’s own hostname instead of the service value the client sent.
• Who may call the key server. It now refuses any bearer token that carries access or context claims, which is what a registry token carries (Red Hat’s Bugzilla report says registry tokens “include access and context claims”). It requires a rotation to carry a key_rotation claim equal to the new key’s ID, and it refuses a token signed for more than five minutes.
• Expiry. A key can no longer be installed without an expiration date: a missing date, or one in the past, returns HTTP 400, and a rotated key’s expiry is capped at the expiry of the key that signed the request.
• Scope. Replacing or deleting a key now matches on the service as well as the key ID.

None of the 11 files is a migration or a clean-up job. As far as the diff shows, a key installed before the update stays in place, which matches Red Hat’s article: the installed key “survives restarts until someone removes it.” We did not run Quay, the new tests (test/test_endpoints.py has 195 added lines) or any exploit.

Who is exposed

• Default settings. In Quay’s config.py at v3.18.2, FEATURE_ANONYMOUS_ACCESS defaults to True, and Red Hat’s article says “Anonymous access is on by default, and with it on, an attacker doesn’t need an account.” With it off, the same article says, “any valid Quay account can still exploit the flaw.”
• The route. web.py registers the key server at /keys with no feature flag, and Quay’s bundled nginx template proxies /keys to the web application on its public listeners with no access rule in that block (conf/nginx/server-base.conf.jnj). We found no configuration setting that turns the key server off.
• Which deployments. Red Hat’s article lists standalone Quay (Podman or Docker), Quay deployed by the Quay Operator on OpenShift and the Mirror registry for Red Hat OpenShift, and says: “Any Quay instance that untrusted clients can reach is exposed. That includes internal registries.”
• How long. Red Hat’s report says the logic is present from the first public commit, and the file history above agrees: the 2019 import of endpoints/keyserver/__init__.py already contains the same signature, audience and issuer check and the same replace_service_key rotation call as v3.18.2 (we compared the two files).
• Exploitation. We found none reported. CISA’s catalog lists neither CVE, EPSS has no score for either, and a search of GitHub repository names for each ID returned no results, which proves little.

What nobody has said yet

• Whether the eight new builds carry the fix for CVE-2026-110697 as well. The second flaw’s CVE page says so; the advisories do not list it.
• When Red Hat will publish anything for Quay 5. Its CVE data lists Quay 5 on quay/quay-rhel9 as affected, but we found no 5.x image among the 82 in that catalog repository, and the redhat-5.0 branch received the fix only at 20:15 UTC on November 11.
• Whether Quay.io was exposed to CVE-2026-123710. Red Hat’s record for the second flaw says it “has already fixed Quay.io”; its record for the first says nothing about it. We also found no release note for the Mirror registry for Red Hat OpenShift either way.
• Whether anyone has installed a signing key through this path. No source we read says so, and none says it did not happen.

What to do

Apply the advisory for your stream

Match the Quay stream you run to the table above and apply that advisory, following the update instructions each advisory links (Red Hat’s article 11258). The 3.18.3 advisory also lists the Quay Operator bundle and its related operator images beside the registry image; we did not check how an Operator-managed deployment picks up the new registry image. If you run Quay 5, a preview build, or Project Quay from the open-source repository, there is no tagged release yet. Pull request 8057 put the change into redhat-5.0 at 20:15 UTC on November 11, pull request 8056 put it into master at 19:43, and every Quay 3 release branch has had it since November 6.

After the update, look for keys that were already installed

Red Hat’s article says the installed key “survives restarts until someone removes it,” and its mitigation says to “remove any unrecognised approved service keys.” In Quay’s data model each service key is a row with an expiration date and an approval. In the rotation code (replace_service_key), the new key copies the replaced key’s name and approval, and the caller’s address goes into its metadata beside created_by set to Key Rotation, so look at creation date, expiry and address rather than the name. Quay’s own instance key is configured to expire (INSTANCE_SERVICE_KEY_EXPIRATION is 120 minutes in config.py), so a key with no expiry is a reason to look, not proof of an attack: an administrator can create one on purpose in the superuser panel.

The query below lists keys with no expiration date. The table and column names come from the ServiceKey and ServiceKeyApproval models in data/database.py at v3.18.2, with the default naming that gives servicekey and servicekeyapproval, so check them against your schema, and run the query on a replica or a restored backup if you can. We ran it only against a throwaway SQLite database holding four made-up rows, not against a Quay database.

-- keys_audit.sql: read-only review of Red Hat Quay service keys (names from the ServiceKey and ServiceKeyApproval models, Quay v3.18.2)
SELECT k.service,
       k.kid,
       k.name,
       k.created_date,
       k.expiration_date,
       a.approval_type,
       k.metadata
FROM servicekey k
LEFT JOIN servicekeyapproval a ON a.id = k.approval_id
WHERE k.expiration_date IS NULL
ORDER BY k.created_date DESC;

Against the made-up rows it printed:

service | kid | name | created_date | expiration_date | approval_type | metadata
quay | kid-pending-0004 | pending | 2026-11-12 03:00:00 | NULL | NULL | {"ip": "198.51.100.9"}
quay | kid-unknown-0003 |  | 2026-11-12 02:10:00 | NULL | Automatic | {"ip": "203.0.113.50", "created_by": "Key Rotation"}
security_scanner | kid-scanner-0002 | scanner | 2026-10-01 09:00:00 | NULL | Super User API | {"created_by": "admin"}
3 rows with no expiration

The first row is a key still waiting for approval (approval_type is NULL). The second has the shape of a rotated key: created by Key Rotation from an address you would have to recognize, no expiry, and an approval copied from the key it replaced. The third is a never-expiring key an administrator created on purpose. The same listing is available on the superuser Service Keys page (the nginx template routes /service-keys to the interface) and through the superuser API route /api/v1/superuser/keys, whose operation is named listServiceKeys.

Check the audit log

The key server writes three event kinds: service_key_create, service_key_rotate and service_key_delete. In the v3.18.2 source, a rotate event records kid, signer_kid, service, name, expiration_date, user_agent and ip, and a delete event records the same fields except expiration_date. Red Hat’s mitigation says to review “service_key_rotate and service_key_delete events with a null expiration_date.” It does not say which fields to read on a delete event, and in the source a delete event has no expiration date to be null, so for deletes read the key ID, the caller’s address and the user agent. On a rotate event, kid is the new key and signer_kid the key that signed the request.

Until you can patch

Red Hat’s mitigation is to “Restrict access to the /keys endpoint at the proxy or load balancer so only trusted internal components can reach it,” and it warns that “Deleting a rogue key is not durable until a fixed build is deployed, because the anonymous request can install a new key.” Quay’s bundled nginx template forwards /keys without any restriction, so the rule belongs in front of Quay, as Red Hat’s wording says. Red Hat’s article also says that “Resetting passwords or regenerating robot tokens does not revoke an unauthorized signing key,” so those steps do not substitute for removing a key.

What we checked

We read SecurityWeek’s report; Red Hat’s CVE pages, JSON data and CSAF (VEX) records for both CVEs; the public part of Red Hat’s subscriber article (the rest is behind a login); Bugzilla bugs 2568072 and 2552237 and their comments through Red Hat’s Bugzilla API; the eight advisory pages; Red Hat’s container catalog API (image tags, push times and advisory IDs); NVD; CISA’s KEV feed; FIRST’s EPSS API; and, on GitHub, quay/quay pull requests 8056 and 8057, the commit histories of the release branches, the tags and releases, and the source files at v3.18.2 and on redhat-3.18. We rendered both CVE pages in a headless browser to read their product tables. We did not run Quay or any exploit, did not send a request to any /keys endpoint and did not contact Red Hat. We could not read the images, Red Hat’s release notes or the paywalled rest of its article. Records and branches change, so the tables show our readings at the times given. “Our reading” and “our arithmetic” mark inferences and counts that are ours, and the SQL query was tested only on made-up rows.

• Report: SecurityWeek, Critical Red Hat Quay Vulnerability Could Expose Private Container Images
• Red Hat: CVE pages for CVE-2026-123710 and CVE-2026-110697, their JSON data and CSAF records (first, second), the article Identifying and remediating unauthorized signing keys in Red Hat Quay, and Bugzilla bugs 2568072 and 2552237
• Advisories: 99019, 99021, 99022, 99023, 99024, 99025, 99026 and 99027, plus the container catalog API
• Records: NVD for CVE-2026-123710 and CVE-2026-110697, CISA’s KEV feed and FIRST’s EPSS API
• Source: quay/quay pull request 8056, pull request 8057, the November 6 commit, the releases page, and at v3.18.2 the files endpoints/keyserver/__init__.py, data/model/service_keys.py, config.py, web.py and conf/nginx/server-base.conf.jnj
• Earlier on sxz.io: Red Hat’s kernel CVE data for CVE-2026-98276, WordPress 7.1.4 and its missing older-branch backports and GitLab, Alpine and the patched Ruby