Is /keys on your Red Hat Quay registries still reachable from untrusted networks?
The official Red Hat CVE record, published on 11 November 2026, describes CVE-2026-123710 in Red Hat Quay 3 (the quay-rhel8 and quay-rhel9 images) and Red Hat Quay 5 (the quay-rhel9 image). Red Hat rates it Critical, CVSS 3.1 9.8, and describes that score as preliminary. An unauthenticated attacker who can reach the key-management endpoint can register their own signing key and then mint tokens for any repository. Red Hat has not published a fixed build. Restrict /keys now.
No fixed build yet. Restrict /keys at the proxy or load balancer. Not in CISA KEV when checked on 11 November 2026.
Red Hat has not published a fixed build for CVE-2026-123710. Its mitigation is to restrict access to the /keys endpoint at the proxy or load balancer so only trusted internal components can reach it. CVE-2026-123710 was not in CISA's Known Exploited Vulnerabilities catalogue when we checked at 16:04 GMT on 11 November 2026 (catalogue 2026.11.10, released at 19:03 UTC on 10 November, before this CVE was published). Recheck KEV. We make no claim either way about exploitation.
By Simon Phillips, CTO. Reviewed by Oliver Legg, Head of SOC and IR. Last updated 11 November 2026, 17:01 GMT.
At a Glance
Based on the official Red Hat CVE page, the official CVE record, Red Hat Bugzilla 2568072, the NVD record, and CISA KEV, as of 11 November 2026. Last updated 11 November 2026, 17:01 GMT.
Critical, CVSS 3.1 9.8
Red Hat rates CVE-2026-123710 Critical, CVSS 3.1 9.8, with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, and describes that score as preliminary and subject to review. The NVD record was in Awaiting Analysis status when we checked, shows the Red Hat 9.8 as Primary, and has not scored it itself.
No fixed build; not in CISA KEV
Red Hat has not published a fixed build, and Bugzilla 2568072 was in NEW status with no fixed-in value when we checked. CVE-2026-123710 was not in CISA KEV when checked at 16:04 GMT on 11 November 2026 (catalogue 2026.11.10, which predates this CVE). Recheck KEV. We make no claim either way about exploitation.
Quay 3 and Quay 5
The official Red Hat CVE page and CVE record list Red Hat Quay 3 (packages quay/quay-rhel8 and quay/quay-rhel9) and Red Hat Quay 5 (package quay/quay-rhel9) as affected. Red Hat says deployments where /keys is reachable by untrusted clients are affected. No package advisories were listed.
Restrict /keys; no fix yet
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, to review audit logs for service_key_rotate and service_key_delete events, and to remove any unrecognised approved service keys. Red Hat warns that deleting a rogue key is not durable until a fixed build is deployed.
The official CVE record's timeline says the issue was reported to Red Hat on 6 November 2026 at 09:44 UTC.
CVE-2026-123710 is reserved.
The official CVE record's timeline lists the issue as made public on 11 November 2026 at 14:00 UTC. The Red Hat CVE page uses the same public date.
The official CVE record for CVE-2026-123710 is published. Red Hat rates it Critical, CVSS 3.1 9.8, and describes that score as preliminary and subject to review.
The NVD record is published, in Awaiting Analysis status, and shows the Red Hat 9.8 as Primary. NVD has not scored it itself.
CVE-2026-123710 is not in CISA KEV catalogue 2026.11.10 (released at 19:03 UTC on 10 November, before this CVE was published). Recheck KEV.
What the official records describe
Red Hat describes this as a Critical flaw that allows an unauthenticated attacker to take over registry token signing. In high-level terms, an unauthenticated attacker who can reach the key-management endpoint can register their own signing key and then mint tokens for any repository. Official records say that key can be created with no expiry, that tokens signed with it are accepted for any repository, and that this allows read and write access to private images and replacement of repository tags. Replacement of repository tags can put a container supply chain at risk.
Red Hat says deployments where /keys is reachable by untrusted clients are affected. The official CVE record lists CWE-1287. The official record credits Red Hat. We do not reproduce the low-level request flow from the official description.
What to Do in the Next 24 Hours
Proactive on the left. Reactive on the right. Vendor steps and our advice are labelled separately.
Restrict /keys and watch for a fix
- Vendor path: Red Hat has not published a fixed build. Its mitigation, quoted, is to restrict access to the /keys endpoint at the proxy or load balancer so only trusted internal components can reach it; to review audit logs for service_key_rotate and service_key_delete events with a null expiration_date, and remove any unrecognised approved service keys; 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. See the Red Hat CVE-2026-123710 page.
- Pack note: Quay's service_key_delete log entry has no expiration_date field. The pack's null-expiry check applies to rotate and approve-type events. The checker flags deletes signed by a different key.
- Our advice: block /keys from untrusted networks now. In nginx, use a ^~ location, because Quay's own regex location overrides a plain location /keys.
- Our advice: check exposure from outside the network, and confirm that /keys is blocked.
- Our advice: deploy Red Hat's fix as soon as it ships, then recheck the service keys. Track the official CVE page and Bugzilla 2568072 for a fixed build.
Hunt and contain
- Our advice: if a rogue key is found, treat all tags as untrusted and compare digests against what your build system pushed.
- Our advice: block /keys before removing the key. Red Hat warns that deleting a rogue key will not last until a fixed build is deployed.
- Vendor path: review audit logs for service_key_rotate and service_key_delete events, and look for unrecognised approved service keys. For how the pack checks those events, see the pack note above.
- Our advice: if a registry may have been abused, rotate credentials and pull secrets that this registry protected, and start incident response if images could have reached other systems.
Proactive: Vendor Steps, Then Ours
Red Hat's mitigation first, then our advice for exposure reduction while there is no fixed build. Our advice is not a substitute for the official Red Hat CVE page, the official CVE record or NVD.
Restrict /keys, as Red Hat directs
Red Hat has not published a fixed build. The official mitigation on the Red Hat CVE-2026-123710 page, quoted, is: restrict access to the /keys endpoint at the proxy or load balancer so only trusted internal components can reach it; review audit logs for service_key_rotate and service_key_delete events with a null expiration_date, and remove any unrecognised approved service keys. Red Hat 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 service_key_delete log entry has no expiration_date field. The pack's null-expiry check applies to rotate and approve-type events. The checker flags deletes signed by a different key.
Block /keys from untrusted networks now
Our advice, not Red Hat's wording: block /keys from untrusted networks now. In nginx, use a ^~ location, because Quay's own regex location overrides a plain location /keys. Check exposure from outside the network, and confirm that /keys is blocked. A deployment is affected, per Red Hat, when untrusted clients can reach /keys.
Deploy the fix when Red Hat ships it, then recheck keys
Our advice: deploy Red Hat's fix as soon as it ships, then recheck the service keys. Watch the official CVE page and Bugzilla 2568072, which listed no fixed-in value and was in NEW status when we checked.
Free Detection Pack
Built by the CybaVerse threat hunt team for businesses, internal IT teams and MSPs. Check exposure offline and hunt for signs of misuse. Everything is read-only.
check-quay-cve-2026-123710.sh
Read-only, offline checker. It reads exported service-key and audit-log files, and an optional nginx or HAProxy config, that an admin hands over. It never contacts a registry or Red Hat, never runs Quay, and writes nothing. There is no version verdict, because Red Hat has not published a fixed build.
bash check-quay-cve-2026-123710.sh --keys keys.json --logs superuser-logs.json --proxy-config nginx.confCheck-QuayCve2026123710.ps1
The same checks in PowerShell 7, with identical output and exit codes. It also runs under PowerShell on Linux.
pwsh -File Check-QuayCve2026123710.ps1 --keys keys.jsonKQL and Sigma
18 KQL hunts (Q1 to Q1f are inventory; Q2 to Q7 are our patterns). 5 Sigma rules, all our patterns. These hunts are CybaVerse hunting ideas, not Red Hat guidance and not IOCs. No IOCs have been published. None of the KQL has been run against a live tenant. Some hunts look at requests to /keys/services/ and /v2/auth. The URL-audience assumption used in a subset of those hunts is our inference.
Verdicts
- SUSPICIOUSAn approved key with no expiration, or for a service you did not list; a rotate or approve-type event with no expiration; or a delete signed by a different key. Review it, it is not proof.
- CHECK EXPOSURENothing SUSPICIOUS, but the proxy config shows no effective /keys restriction.
- UNKNOWNA key could not be judged, or an export was empty.
- NO FINDINGSNothing matched in the files that were supplied.
Exit codes
| Code | Meaning |
|---|---|
| 0 | NO FINDINGS |
| 1 | SUSPICIOUS |
| 3 | UNKNOWN |
| 4 | Usage or read error |
| 5 | CHECK EXPOSURE |
The proxy-config check is our heuristic over a single file. It does not follow includes, routes or cloud load-balancer rules. Always test from an untrusted network.
Know the limits
- Q2 to Q7, and all five Sigma rules, are our own patterns, not Red Hat's. Q1 to Q1f are inventory. None of these hunts prove exploitation.
- The URL-audience assumption is our inference. It is unverified that an attack always looks like this, or that no legitimate client does.
- None of the KQL has been run against a live tenant.
- No IOCs have been published.
- Webserver and proxy Sigma rules convert only where a matching table exists.
- Quay's service_key_delete log entry has no expiration_date field. The pack's null-expiry check applies to rotate and approve-type events. The checker flags deletes signed by a different key.
What is in the pack
| File | What it does |
|---|---|
| check-quay-cve-2026-123710.sh | Read-only checker for Linux and macOS (bash) |
| Check-QuayCve2026123710.ps1 | The same checker in PowerShell 7 |
| KQL (18 hunts) | Q1 to Q1f inventory; Q2 to Q7 our patterns |
| Sigma (5 rules) | All our patterns, plus Kusto conversions (in the full pack) |
| tests/ | Fixtures and tests (in the full pack; 55 files in total) |
| README.md | Verified facts, Red Hat's advice versus ours, limits and usage |
Reactive: How to Hunt (Our Advice)
The hunts below, and the pack downloads, are CybaVerse advice. Q2 to Q7 and all five Sigma rules are our own patterns. Q1 to Q1f are inventory.
Find reachable Quay registries
Inventory Red Hat Quay 3 and Quay 5 registries, including quay-rhel8 and quay-rhel9 images, and check exposure from outside the network. Confirm that /keys is blocked. These are our patterns for finding exposure, not official indicators. Use the pack checker and the Q1 inventory hunts.
Review key-management audit events
Follow Red Hat's mitigation: review audit logs for service_key_rotate and service_key_delete events, and look for unrecognised approved service keys. The pack checker can help. Quay's service_key_delete log entry has no expiration_date field, so the pack's null-expiry check applies to rotate and approve-type events, and the checker flags deletes signed by a different key.
If a rogue key is found
Our advice: block /keys before removing the key, because Red Hat warns that deleting a rogue key is not durable until a fixed build is deployed. Treat all tags as untrusted and compare digests against what your build system pushed.
If you find signs of compromise (our advice)
- Block /keys from untrusted networks before you remove unrecognised keys.
- Treat all repository tags as untrusted and compare digests against what your build system pushed, and before promoting an image into another environment.
- Keep audit logs, registry events and a record of approved service keys for investigation.
- Rotate credentials, pull secrets and any other secrets that this registry protected.
- Start incident response if private images may have been read or if tags may have been replaced.
Red Hat Quay CVE-2026-123710 FAQ
Short answers based on the official Red Hat CVE page, the official CVE record, Red Hat Bugzilla 2568072, the NVD record, and CISA KEV, checked on 11 November 2026.
What is CVE-2026-123710?
The official Red Hat CVE record, published on 11 November 2026, covers Red Hat Quay 3 (quay-rhel8 and quay-rhel9) and Red Hat Quay 5 (quay-rhel9). In high-level terms, an unauthenticated attacker who can reach the key-management endpoint can register their own signing key and then mint tokens for any repository. Official records say that key can have no expiry, and that those tokens allow read and write access to private images and replacement of repository tags. The official record credits Red Hat.
How severe is it?
Red Hat rates CVE-2026-123710 Critical, CVSS 3.1 9.8, with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, and describes that score as preliminary and subject to review. The NVD record was in Awaiting Analysis status when we checked on 11 November 2026, shows the Red Hat 9.8 as Primary, and has not scored it itself. Official records list CWE-1287.
Is this being exploited, or is it in CISA KEV?
CVE-2026-123710 was not in CISA's Known Exploited Vulnerabilities catalogue when we checked at 16:04 GMT on 11 November 2026 (catalogue 2026.11.10, released at 19:03 UTC on 10 November, before this CVE was published). Recheck KEV. We make no claim either way about exploitation.
Which software is affected, and is there a fix?
The official Red Hat CVE page and CVE record list Red Hat Quay 3 (packages quay/quay-rhel8 and quay/quay-rhel9) and Red Hat Quay 5 (package quay/quay-rhel9) as affected. Red Hat says deployments where /keys is reachable by untrusted clients are affected. No package advisories were listed, and Bugzilla 2568072 was in NEW status with no fixed-in value when we checked. There is no published fixed build yet.
What should we do first?
Follow Red Hat's mitigation: restrict /keys at the proxy or load balancer to trusted internal components, review audit logs, and remove unrecognised approved service keys. Our advice, not Red Hat's: block /keys from untrusted networks now (in nginx, use a ^~ location, because Quay's own regex location overrides a plain location /keys); check exposure from outside the network; deploy the fix when it ships, then recheck keys; if a rogue key is found, treat all tags as untrusted and compare digests against what your build system pushed, and block /keys before removing the key.
Who is this relevant to?
Organisations and MSPs that run Red Hat Quay 3 or Red Hat Quay 5 registries, especially where untrusted clients or the internet can reach /keys. Official records list those Quay product lines and images only.
Protect Your Registries, and the Images They Hold
CybaOps monitors your servers, endpoints and cloud workloads, whether that's your own business or your clients'. UK-based analysts monitor alerts 24/7, run these threat hunts and act on pre-approved response actions, and CybaOps drives remediation through to a verified fix, so proactive checks and reactive response happen in one place.
Sources
- Red Hat: CVE-2026-123710 (Critical, CVSS 3.1 9.8, described as preliminary and subject to review; made public 11 November 2026, 14:00 UTC; page checked 11 November 2026)
- Official CVE record: CVE-2026-123710 (published 11 November 2026, 15:02 UTC)
- Red Hat Bugzilla 2568072 (status NEW when checked on 11 November 2026; no fixed-in value listed)
- NVD: CVE-2026-123710 (Awaiting Analysis; shows the Red Hat CVSS 3.1 9.8 as Primary; NVD has not scored it itself; published 11 November 2026, 15:17 UTC)
- CISA: Known Exploited Vulnerabilities catalogue (checked 11 November 2026, 16:04 GMT; catalogue 2026.11.10, released 10 November 2026 at 19:03 UTC)