CVE-2026-123710: Critical Red Hat Quay Flaw
Critical CVSS (9.8) reachable over network.
TL;DR - CVE-2026-123710 is a critical Red Hat Quay authorization and signing-key management flaw with a reported CVSS score of 9.8. - An unauthenticated attacker may install an attacker-controlled signing key and mint tokens for arbitrary repositories. - No verified public PoC or in-the-wild exploitation is known; confirm the vendor fix and investigate immediately.
Vulnerability at a Glance
| Field | Value |
|---|---|
| CVE ID | CVE-2026-123710 |
| Product | Red Hat Quay |
| CVSS score | 9.8, Critical |
| Attack vector | Network-based; remotely exploitable |
| Authentication required | None reported |
| Privileges required | None reported |
| Patch available | Not confirmed in the retrieved advisory content |
| CISA KEV status | Not listed as of 2026-11-11 |
| Public PoC | No verified public PoC identified |
| Known exploitation | No independently verified in-the-wild exploitation identified |
CVE-2026-123710 affects Red Hat Quay, a container registry platform used to store, distribute, and control access to container images. The reported impact is serious: the flaw may allow an unauthenticated party to introduce a signing key that Quay subsequently trusts.
A successful attack could provide read and write access to private repositories, enable replacement of image tags, and undermine deployment trust. Treat a potentially affected Quay instance as a software supply-chain control-plane risk, not merely as an isolated registry authentication issue.
For broader context on application security weaknesses, see this SQL injection overview. Container registry operators should also review their broader container supply-chain security practices.
What Is This Vulnerability?
The reported vulnerability is an authorization failure in the service key rotation workflow. An unauthenticated client can obtain an anonymous registry token while controlling or influencing the token’s audience value. The attacker then presents that token to Quay’s service key rotation endpoint.
According to the vulnerability description, Quay accepts the request and installs the attacker’s signing key as an approved service key. The installed key has no expiry. Once the key is trusted, the attacker can sign registry tokens for arbitrary repositories. Quay accepts those tokens, granting access that may include pulling private images, pushing content, and replacing repository tags.
The apparent root cause is a combination of insufficient authorization at the key rotation endpoint, inadequate validation of an attacker-controlled token audience, and failure to enforce key lifetime or constrain which principals can rotate signing keys. The available research material does not provide the complete implementation details, endpoint path, request schema, or vulnerable source-code change. Defenders should not assume that a particular URL or API format is authoritative.
This attack chain crosses several trust boundaries:
- Anonymous token issuance.
- Token audience validation.
- Service signing-key rotation.
- Token signature verification.
- Repository authorization.
Breaking any one of these links may prevent exploitation, but only the vendor’s corrective release should be treated as a complete remediation.
Analyst’s Take: The key issue is not only unauthorized repository access; it is the reported ability to insert a signing key into Quay’s trust path and then mint tokens for arbitrary repositories. Until Red Hat confirms the affected and fixed builds, operators should prioritize key and token review alongside restricting access to key-rotation functionality.
Who Is Affected?
The affected product is Red Hat Quay. The available NVD and retrieved Red Hat advisory content identifies the product but does not expose a complete affected-version table.
| Product | Affected version range | Fixed version |
|---|---|---|
| Red Hat Quay | Not established from the retrieved primary-source content | Not established from the retrieved primary-source content |
Do not infer a version range from the CVE identifier, publication date, or a locally installed package name. Red Hat Quay deployments can include different release branches, operator-managed installations, standalone deployments, and platform-integrated configurations. The authoritative mapping must come from the applicable Red Hat security erratum or updated CVE advisory.
Inventory every Quay deployment, including development registries, disconnected environments, disaster-recovery instances, and registries exposed through reverse proxies. A deployment may remain at risk even if its primary user interface is restricted, because registry token and administrative service endpoints may be reachable through separate routes or trusted internal networks.
Check the Red Hat security portal and subscribed errata channels for the specific Quay release branch and fixed build:
Until Red Hat publishes or confirms the applicable fixed version, mark the patch state as unconfirmed, not as “not affected.”
CVSS Score Breakdown
The reported base score for CVE-2026-123710 is 9.8, Critical. The supplied record did not include the complete CVSS vector string. Therefore, the individual metric values below are an interpretation of the reported attack scenario, not a replacement for the authoritative vector.
| CVSS consideration | Reported or inferred status |
|---|---|
| Attack vector | Network |
| Attack complexity | Not confirmed |
| Privileges required | None reported |
| User interaction | Not confirmed; the described attack does not appear to require a victim |
| Scope | Not confirmed |
| Confidentiality impact | High potential impact through private image access |
| Integrity impact | High potential impact through image and tag modification |
| Availability impact | Potentially high, depending on registry and repository effects |
The 9.8 score is consistent with a remotely reachable issue requiring no authenticated account and affecting all three primary security objectives. Confidentiality is impacted because private images may be readable. Integrity is impacted because an attacker may push content or replace tags. Availability may be affected if repositories, manifests, or registry operations are disrupted, although the supplied material does not describe a specific denial-of-service mechanism.
Because the CVSS vector is absent from the supplied NVD result, organizations should avoid publishing an invented vector string or assuming exact values for scope, attack complexity, and user interaction. Confirm those metrics against the complete NVD JSON record or the Red Hat advisory when available. The 9.8 score should nevertheless drive urgent triage because the described consequence is a registry-wide authorization bypass.
Exploitation Status
CVE-2026-123710 is not listed in the CISA Known Exploited Vulnerabilities catalog based on the lookup supplied for this assessment. No CISA dateAdded, due date, required action, or ransomware-campaign flag was returned.
No independently verified in-the-wild exploitation was identified in the sources checked. This is not proof that exploitation has not occurred. CISA KEV coverage is not exhaustive, and newly published vulnerabilities can be exploited before public reporting or catalog inclusion. Organizations should use local telemetry and threat-intelligence sources in addition to KEV status.
No verified public GitHub proof of concept or exploit repository was identified in the searches performed. Search results that refer to other 2026 vulnerabilities should not be attributed to this CVE. The absence of a public PoC should not be interpreted as low risk: the described attack chain concerns standard registry token and key-management functions, and a capable attacker may be able to reproduce it without publishing code.
Treat the exploitation status as follows:
- Confirmed in-the-wild exploitation: No verified report identified.
- Public PoC: No verified public PoC identified.
- CISA KEV: Not listed.
- Operational priority: High, because successful exploitation could compromise private images and software distribution.
How to Detect It
Detection should focus on unexpected use of anonymous token issuance, unusual token audiences, calls to service key rotation functionality, new signing keys, and repository activity that does not match known automation. The exact endpoint path and log field names were not provided, so detections must be adapted to the Quay version, deployment mode, reverse proxy, and central logging format.
Start by preserving Quay application logs, reverse-proxy access logs, identity-provider logs, Kubernetes audit logs if Quay is operator-managed, and registry audit events. Establish a timeline covering at least the period since the last trusted signing-key inventory. Pay particular attention to events that occur without an authenticated principal or that originate from networks not normally used by registry administrators.
Technical Notes
A generic web-server or reverse-proxy hunting pattern can identify requests associated with anonymous token flows and key-management activity. Replace the placeholder path with the endpoint recorded in your Quay deployment; do not assume the following strings are the vendor’s exact route names.
# Search compressed and uncompressed access logs for likely token/key-management activity.
zgrep -hEi \
'(/token|/oauth|audience=|service.?key|key.?rotation|rotate.*key|signing.?key)' \
/var/log/nginx/access.log* \
/var/log/httpd/access_log* 2>/dev/null
A SIEM query should correlate unauthenticated requests with subsequent key or repository events. For example, the following pseudocode expresses the detection logic without claiming a vendor-specific schema:
FROM quay_access_events
WHERE (endpoint CONTAINS "token"
OR query CONTAINS "audience"
OR endpoint CONTAINS "key")
AND authenticated_principal IS NULL
AND source_ip NOT IN approved_registry_automation
JOIN quay_audit_events
ON source_ip AND time BETWEEN request_time AND request_time + 10m
WHERE event_type IN ("signing_key_added",
"service_key_rotated",
"repository_push",
"manifest_updated",
"tag_replaced")
Audit the current signing-key set and compare it with a known-good inventory. Flag keys with unknown ownership, unexpectedly long validity, missing expiry, or creation times that coincide with suspicious token requests. Review repository events for tag movement that is not explained by a release pipeline. A tag replacement is especially important because mutable tags may cause existing deployments or newly provisioned hosts to retrieve attacker-controlled content.
If compromise is suspected, collect key identifiers, token claims, source addresses, repository names, manifest digests, and timestamps before rotating or deleting evidence. Avoid relying only on current registry state: an attacker may have replaced a tag and later restored it, while an image digest or audit record still reveals the change.
Mitigation and Patching
A fixed Red Hat Quay version was not established from the retrieved primary-source content. The required action is to obtain the applicable Red Hat erratum for each deployed Quay release branch and upgrade to the vendor-specified fixed build. Do not substitute an assumed version number.
Until the fixed version is confirmed and deployed, restrict access to the service key rotation capability where operationally possible. Use network policy, reverse-proxy controls, firewall rules, or an administrative access path that is unavailable to anonymous clients. Test these controls carefully because blocking registry token flows broadly can interrupt legitimate image pulls and pushes.
Review all configured service signing keys. Remove unknown keys only after preserving forensic evidence and coordinating with the Quay administrator. If an unauthorized key may have been installed, rotate legitimate signing keys and invalidate or revoke tokens issued under potentially compromised keys according to Red Hat’s documented operating procedure. Image consumers should be moved from mutable tags to verified immutable digests and signatures while the investigation is underway.
Technical Notes
The upgrade command depends on how Quay is deployed. The following examples are intentionally conditional and must be adapted to the authoritative Red Hat release instructions. Do not run an unverified package or image name in production.
For an operator-managed Quay deployment, first inspect the installed resource and image reference, then update it to the vendor-provided fixed image:
# Inspect the current Quay operator and registry image references.
kubectl -n quay get quayregistry -o yaml
kubectl -n quay get deployment -o wide
# After Red Hat confirms the fixed image reference:
kubectl -n quay edit quayregistry <quayregistry-name>
# Set the deployment's image or operator-controlled version to the
# Red Hat-provided fixed build, then monitor rollout status.
kubectl -n quay rollout status deployment/<quay-deployment-name>
For a package- or appliance-managed installation, use the Red Hat-provided update procedure rather than guessing a package version:
# Review available Red Hat advisories and installed Quay-related packages.
subscription-manager refresh
dnf updateinfo list cves | grep -i 'CVE-2026-123710'
rpm -qa | grep -i quay
# After confirming the applicable fixed advisory and package set:
dnf update <vendor-specified-quay-packages>
The commands above do not establish that a fixed package is currently available. They provide a safe verification workflow. Record the resulting image digest or package NEVRA, verify that the running deployment matches it, and retain the change record for incident response and compliance purposes.
If a complete vendor workaround is not available, use layered interim controls:
- Restrict external and unauthenticated reachability to key-rotation functionality.
- Permit registry operations only through approved network paths where feasible.
- Monitor anonymous token requests and unusual audiences.
- Audit and reconcile signing keys.
- Review private image access and repository mutations.
- Enforce digest and signature verification in deployment pipelines.
- Rotate credentials and signing material if unauthorized activity is found.
These controls reduce exposure but do not correct the underlying authorization flaw. Schedule the vendor upgrade as soon as the fixed Quay build is confirmed.
References
The following sources support the vulnerability identity, severity, product attribution, and current exploitation assessment:
- NVD: CVE-2026-123710
- Red Hat Security Advisory: CVE-2026-123710
- Red Hat Bugzilla issue 2568072
- CISA Known Exploited Vulnerabilities Catalog
The NVD result supplied for this assessment reports a CVSS score of 9.8 but does not expose the complete vector string. The retrieved Red Hat material also did not provide a complete affected-version range or fixed-version mapping. Confirm those fields against the current Red Hat erratum before publishing a definitive upgrade target.
The evidence supports urgent investigation and remediation planning, but it does not support claiming confirmed exploitation, a public exploit, or a specific fixed Quay version. Organizations should first document the advisory status and deployed Quay build, then reconcile the signing-key inventory and check repository and image integrity.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.