CTIPilot
AI-generated · no human review · verify critical claims against the linked source. how it works →

Red Hat Quay

product · product:red-hat-quay single-source

Coverage
1
first 2026-11-14 → last 2026-11-14
Latest activity
2026-11-14
Red Hat Quay: anonymous signing-key takeover and cross-tenant token theft; update to your branch's fixed…
Peak priority
notable
1 notable
Targets
technology
sectors: technology
Sources cited
5
3 hosts

Action items (1)

Do-now tasks recorded on the entries about Red Hat Quay, newest first. Check the date before acting on an older one.

  • Update every Red Hat Quay registry to its branch's fixed release (3.9.28, 3.10.28, 3.12.24, 3.14.10, 3.15.9, 3.16.7, 3.17.7 or 3.18.3) and, until then, restrict the /keys endpoint at the proxy or load balancer to trusted internal components; on any instance whose /keys endpoint untrusted clients could reach, review audit logs for service_key_rotate and service_key_delete events with a null expiration_date and remove unrecognised approved service keys, because deleting a rogue key is not durable before the fix and resetting passwords or regenerating robot tokens does not revoke it.
    2026-11-14CVE-2026-123710 +1

Defender insights

What each entry about Red Hat Quay tells a defender to do, newest first.

2026-11-14NOTABLERed Hat Quay: anonymous signing-key takeover and cross-tenant token theft; update to your branch's fixed release

Exposure · detection

Story timeline

  1. 2026-11-14CVE-2026-123710 and CVE-2026-110697, Red Hat Quay: an anonymous client can install its own registry signing key and read or overwrite every private image (CVSS 3.1 9.8), and a low-privilege account can steal other tenants' robot tokens (9.9); fixed in Quay 3.9.28 to 3.18.3, no fix for Quay 5 or the mirror registry, no exploitation reported
    trending-vulnerabilitiesRed Hat Quay: anonymous signing-key takeover and cross-tenant token theft; update to your branch's fixed release
ATT&CK techniques (6 across 4 tactics)

6 techniques observed across 1 entry about this entity, derived from entry metadata and body evidence, never asserted without a published entry behind it · pinned to MITRE ATT&CK v20.1 · compare on the matrix · Navigator layer (JSON)

  • Initial AccessExploit Public-Facing Application · Supply Chain Compromise: Compromise Software Supply Chain
  • PersistenceImplant Internal Image
  • Credential AccessSteal Application Access Token · Forge Web Credentials
  • Lateral MovementUse Alternate Authentication Material: Application Access Token

Initial Access TA0001

T1190Exploit Public-Facing Application×1

Adversaries may attempt to exploit a weakness in an Internet-facing host or system to initially access a network. The weakness in the system can be a software bug, a temporary glitch, or a misconfiguration.

Evidence: 2026-11-14/red-hat-quay-signing-key-takeover-cve-2026-123710 · ATT&CK page ↗

T1195.002Supply Chain Compromise: Compromise Software Supply Chain×1

Adversaries may manipulate application software prior to receipt by a final consumer for the purpose of data or system compromise. Supply chain compromise of software can take place in a number of ways, including manipulation of the application source code, manipulation of the update/distribution mechanism for that software, or replacing compiled releases with a modified version.

Evidence: 2026-11-14/red-hat-quay-signing-key-takeover-cve-2026-123710 · ATT&CK page ↗

Persistence TA0003

T1525Implant Internal Image×1

Adversaries may implant cloud or container images with malicious code to establish persistence after gaining access to an environment. Amazon Web Services (AWS) Amazon Machine Images (AMIs), Google Cloud Platform (GCP) Images, and Azure Images as well as popular container runtimes such as Docker can be implanted or backdoored. Unlike Upload Malware, this technique focuses on adversaries implanting an image in a registry within a victim’s environment. Depending on how the infrastructure is provisioned, this could provide persistent access if the infrastructure provisioning tool is instructed to always use the latest image.

Evidence: 2026-11-14/red-hat-quay-signing-key-takeover-cve-2026-123710 · ATT&CK page ↗

Credential Access TA0006

T1528Steal Application Access Token×1

Adversaries can steal application access tokens as a means of acquiring credentials to access remote systems and resources.

Evidence: 2026-11-14/red-hat-quay-signing-key-takeover-cve-2026-123710 · ATT&CK page ↗

T1606Forge Web Credentials×1

Adversaries may forge credential materials that can be used to gain access to web applications or Internet services. Web applications and services (hosted in cloud SaaS environments or on-premise servers) often use session cookies, tokens, or other materials to authenticate and authorize user access.

Evidence: 2026-11-14/red-hat-quay-signing-key-takeover-cve-2026-123710 · ATT&CK page ↗

Lateral Movement TA0008

T1550.001Use Alternate Authentication Material: Application Access Token×1

Adversaries may use stolen application access tokens to bypass the typical authentication process and access restricted accounts, information, or services on remote systems. These tokens are typically stolen from users or services and used in lieu of login credentials.

Evidence: 2026-11-14/red-hat-quay-signing-key-takeover-cve-2026-123710 · ATT&CK page ↗

Entries about Red Hat Quay (1)

2026-11-14 · view entry permalink →

NOTABLECVE-2026-123710 +1NATOA2

CVE-2026-123710 and CVE-2026-110697, Red Hat Quay: an anonymous client can install its own registry signing key and read or overwrite every private image (CVSS 3.1 9.8), and a low-privilege account can steal other tenants' robot tokens (9.9); fixed in Quay 3.9.28 to 3.18.3, no fix for Quay 5 or the mirror registry, no exploitation reported

Red Hat's record for CVE-2026-123710 says an unauthenticated client of Red Hat Quay can obtain an anonymous registry token with an audience it chooses, present it to the service-key rotation endpoint and install its own approved signing key with no expiry (Red Hat, 2026-11-11). NCSC Switzerland summarises the impact as letting network attackers with anonymous or low-privileged access read, overwrite or poison private container images and steal registry credentials, compromising the software supply chain (NCSC Switzerland, 2026-11-13). The condition is that the /keys endpoint is reachable by untrusted clients (Red Hat, 2026-11-11); anonymous access is on by default, and turning it off does not protect, because any valid Quay account can still exploit the flaw (Red Hat, 2026-11-13).

CVE-2026-110697 lets an attacker who creates a namespace containing an underscore match and retrieve robot accounts and their decrypted tokens from other tenants' namespaces; Red Hat says it needs no elevated privileges or victim interaction and that, where Quay is OpenShift's integrated registry, stolen robot credentials can inject malicious images into CI/CD pipelines (Red Hat, 2026-11-11).

Red Hat's page for the second flaw lists the fixed builds 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 and says Quay.io is already fixed (Red Hat, 2026-11-11); its CSAF record for the first flaw links eight Quay errata, RHSA-2026:99019 and 99021 to 99027, as its fixes and lists Red Hat Quay 5 and the mirror registry for Red Hat OpenShift 2 as affected with no fix available (Red Hat, 2026-11-13). NCSC Switzerland lists the exploitation status as unknown (NCSC Switzerland, 2026-11-13).

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.

Update to the fixed Red Hat Quay release for your version: 3.9.28, 3.10.28, 3.12.24, 3.14.10, 3.15.9, 3.16.7, 3.17.7, or 3.18.3.

Red Hat
vulnerability14 Nov 04:08Zsingle-sourceOpen finding →

Co-occurring entities

Derived: referenced by the same focused operational entries (weekly summaries and report roundups don't count); ×N counts the shared entries.

Where this entity is cited

  • Vulns1

Source distribution

  • access.redhat.com3 (60%)
  • security-hub.ncsc.admin.ch1 (20%)
  • security.access.redhat.com1 (20%)