CVE
Quay: red hat quay: unauthenticated registry signing-key takeover via service key rotation
Affects Red Hat Quay deployments where the /keys service key rotation endpoint is reachable by untrusted clients. No fixed version is listed; restricting /keys at the proxy is the stated workaround.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Exploited
- No known exploitation
- Fix
- See vendor advisory
- Who is exposed
- Not reported
Do first: Workaround: Restrict access to the /keys endpoint at the proxy or load balancer so only trusted internal components can reach it.
- Last modified
- Whether it needs action now or is a reference record, by fixed rules, with why. Last checked is when cve.now last re-read it.What do these mean? →
- Reference
- Last checked
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 42/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Unclear
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
Red Hat Quay is affected. Remotely and without logging in, an attacker can register their own signing key with the registry's key rotation endpoint, then use it to read and write private images and replace repository tags.
Read the original description
A flaw was found in Red Hat Quay. An unauthenticated client can obtain an anonymous registry token with an audience it controls, present that token to the service key rotation endpoint, and install its own approved signing key with no expiry. Registry tokens signed with that key are accepted for any repository, allowing read and write access to private images and replacement of repository tags.
Who should check
Teams running Red Hat Quay where the /keys endpoint is reachable by untrusted clients.
Not fixed by: Deleting a rogue key is not durable until a fixed build is deployed.
Read the source excerpt
“Deployments where /keys is reachable by untrusted clients are affected.”
cve.now Index
- Exploitation?/40Unknown. No CISA SSVC exploitation rating yet
- Exposure17/25No login or user action needed, reachable over the network without a login · Unknown: Advisories don't say whether default setups are affected
- Reach10/20Shipped in major Linux distributions
- Severity9.8/10CVSS 9.8
- No patch5/5No fixed version listed; see vendor advisory
What would change the score
- Would score about 87 if added to CISA KEV
- Would score about 82 if CISA's SSVC rates exploitation active
- Would score about 47 if advisories confirm default setups are exposed
What to do
Workaround: Restrict access to the /keys endpoint at the proxy or load balancer so only trusted internal components can reach it.
Check your systems with an agent
Paste this into a coding or ops agent. It checks your systems read-only and reports a table per asset.
Check whether my systems are affected by CVE-2026-123710 (Quay: red hat quay: unauthenticated registry signing-key takeover via service key rotation), using the cve.now data below.
Rules: work read-only. Do not run exploit code, proof-of-concept scripts or scanners that send attack payloads, and do not change any configuration, package, image or deployment. Report findings only.
What cve.now has for CVE-2026-123710 (entry last updated 2026-11-11):
Affected:
- Red Hat Red Hat Quay 3: version range not reported
- Red Hat Red Hat Quay 3: version range not reported
- Red Hat Red Hat Quay 5: version range not reported
Fixed versions: none listed yet.
Conditions (all must be true for the bug to be hit):
- The /keys service key rotation endpoint is reachable by untrusted clients. (source: https://access.redhat.com/security/cve/cve-2026-123710)
Setup: unknown whether the bug needs a non-default feature or setting. Check the advisory.
Attacker needs: network access, no login, no user action.
Workaround: Restrict access to the /keys endpoint at the proxy or load balancer so only trusted internal components can reach it. (source: https://www.cve.org/CVERecord?id=CVE-2026-123710)
CISA KEV: CVE-2026-123710 is not listed as of cve.now's last read.
This KEV status is for CVE-2026-123710 only. If you also check another CVE, look up its own KEV status; never assume it from this one.
How to check:
- Installed software: check what is actually running, not what a repo declares. Read the version from each host, container image and Kubernetes node (the binary's version output, the OS package database, image layers), and check whether the conditions above hold there. Distribution packages may carry a backported fix under an older version number; confirm against the distribution's own advisory.
Verify against the linked advisories before concluding, and cite the date you read each one:
- https://bugzilla.redhat.com/show_bug.cgi?id=2568072
- https://access.redhat.com/security/cve/CVE-2026-123710
- https://www.cve.org/CVERecord?id=CVE-2026-123710
- https://access.redhat.com/security/cve/cve-2026-123710
Do not conclude an asset is unaffected unless you checked it and the evidence covers both its version and the conditions above. If you could not check something, mark it unknown and say what is missing.
Report a table with one row per asset and these columns: Asset | Version or build | Status (affected, fixed, not applicable, unknown) | Compensating controls | Exposure (internet-facing, internal, none) | Evidence | Next action.
Entry: https://cve.now/CVE-2026-123710
For follow-up questions, use the cve.now MCP server at https://mcp.cve.now/mcp (no authentication), for example execute with name cve.get and arguments {"id": "CVE-2026-123710"}.Timeline
- CVE published
- First seen by cve.now
- Posted on X by cve.now
Affected versions
- quay/quay-rhel8
Version range not reported
- quay/quay-rhel9
Version range not reported
- quay/quay-rhel9
Version range not reported
Evidence 4
CVE record · 2
Establishes: The identifier and description.
- Record
- Record
Write-ups · 1
Establishes: Technical detail and context.
- Report
Other links · 1
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-123710
Is CVE-2026-123710 being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data
What does this mean?
The /keys endpoint, used to rotate the service key, can be reached by untrusted clients. An attacker can install its own signing key, gaining read and write access to private images and the ability to replace repository tags.Source: access.redhat.com, cve.org
Am I affected, and how do I check?
The advisory names Red Hat Quay 3 and Red Hat Quay 5 but lists no affected version ranges. The affected setup is a deployment where the /keys endpoint is reachable by untrusted clients, so check whether that path is exposed through the proxy or load balancer.Source: access.redhat.com, cve.org
How do I fix CVE-2026-123710?
The facts list no fixed version, so no upgrade target can be given. Restrict access to the /keys endpoint at the proxy or load balancer so only trusted internal components can reach it.Source: access.redhat.com, cve.org
What if there's no patch?
Restrict access to the /keys endpoint at the proxy or load balancer so only trusted internal components can reach it. This limits the affected feature until a fix is available.Source: access.redhat.com, cve.org