Silent Registry Takeover: How Two Critical Red Hat Quay Flaws Can Poison Your Entire Container Supply Chain
Executive Summary
Executive Summary In November 2026, Red Hat disclosed two critical vulnerabilities in its Quay container registry platform—CVE-2026-123710 (CVSS 9.8) and CVE-2026-110697 (CVSS 9.9)—that together allow unauthenticated or low-privilege attackers to read, overwrite, and inject malicious container images across all repositories in a registry. CVE-2026-123710 exploits a trust-key injection flaw present since Quay's first public commit, enabling persistent unauthorized token signing without expiry. CVE-2026-110697 leverages an unescaped SQL LIKE wildcard in namespace lookups to steal robot account tokens from other tenants, enabling cross-tenant image manipulation and CI/CD pipeline poisoning in OpenShift environments. Both flaws affect all Quay 3 and Quay 5 versions, with patches available for eight Quay 3 branches.
These vulnerabilities represent a severe supply-chain risk as container registries sit at the heart of modern software delivery pipelines. The ability to silently overwrite images means malicious code can propagate to every downstream system pulling from the registry, echoing the trajectory of high-impact software supply-chain attacks. With CI/CD pipeline integrity under increasing regulatory and industry scrutiny, organizations running Quay—especially on OpenShift—face immediate exposure requiring urgent patching and audit.
Why This Matters Now
Why This Matters NowContainer registries are the trust anchors of cloud-native software supply chains, and these flaws allow silent, persistent image poisoning without elevated privileges. As enterprises accelerate Kubernetes and OpenShift adoption, a single compromised registry can cascade malicious code to thousands of production workloads. With supply-chain attacks rising sharply and regulators tightening software integrity requirements under frameworks like SSDF and EO 14028, unpatched Quay instances represent a critical and immediate organizational liability.
Attack Path Analysis
Attack Path AnalysisAn unauthenticated or low-privileged attacker exploited CVE-2026-123710 in Red Hat Quay to inject a trusted signing key with no expiry into the registry's key server, bypassing all token validation and gaining the ability to sign arbitrary access tokens for any repository. Using forged tokens, the attacker escalated to full registry control, moved laterally across tenants via CVE-2026-110697's SQL wildcard injection to harvest robot account credentials, exfiltrated private container images and embedded secrets, and ultimately overwrote production images to poison downstream CI/CD pipelines and OpenShift deployments at scale.
Kill Chain Progression
Kill Chain ProgressionThis analysis maps confirmed threat intelligence to the full cloud kill chain to show where defensive gaps would emerge as an attack progresses.
Initial Compromise
Description
DescriptionThe attacker accessed Quay's publicly reachable /keys endpoint and the /v2/auth anonymous token endpoint. With anonymous access enabled (the default), no credentials were required. The attacker obtained an anonymous token signed by Quay with a trusted key, then submitted a key-rotation request to the key server using that token as proof of trust — exploiting CVE-2026-123710, which does not verify that a token was issued for key rotation purposes. This allowed the attacker to register an attacker-controlled signing key with no expiration date as a trusted key in the registry.
Related CVEs
Related CVEsCVE-2026-123710
CVSS 9.8A critical authentication bypass flaw in Red Hat Quay allows an unauthenticated or low-privileged attacker to inject a trusted signing key with no expiry into the registry key server, enabling read and overwrite access to all private container images across every repository in the registry.
Affected Products:
Red Hat Quay – < fixed Quay 3 builds (all Quay 3.x and Quay 5.x versions prior to patched releases)
Red Hat OpenShift Integrated Registry (via Quay Operator) – all versions prior to patched Quay 3 builds
Red Hat Mirror Registry for Red Hat OpenShift – all versions prior to patched Quay 3 builds
Exploit Status:
no public exploitCVE-2026-110697
CVSS 9.9A critical SQL wildcard injection flaw in Red Hat Quay's robot account listing logic allows any authenticated user who can create a namespace to steal decrypted robot account tokens belonging to other tenants, enabling unauthorized read, push, and overwrite of those tenants' container images.
Affected Products:
Red Hat Quay – < fixed Quay 3 builds (all Quay 3.x and Quay 5.x versions prior to patched releases)
Red Hat Quay.io (cloud-hosted) – patched at time of disclosure
Exploit Status:
no public exploit
MITRE ATT&CK® Techniques
MITRE ATT&CK® TechniquesUnsecured Credentials: Credentials In Files
Use Alternate Authentication Material: Application Access Token
Supply Chain Compromise: Compromise Software Supply Chain
Implant Internal Image
Exploit Public-Facing Application
Valid Accounts: Cloud Accounts
Data Manipulation: Stored Data Manipulation
Data from Cloud Storage
Potential Compliance Exposure
Potential Compliance ExposureMapping incident impact across multiple compliance frameworks.
PCI DSS 4.0 – Timely Patching of Software Vulnerabilities
Control ID: Requirement 6.3.3
NYDFS 23 NYCRR 500 – Least-Privilege Access and Credential Governance
Control ID: Section 500.07 — Access Privileges and Management
DORA (EU 2022/2554) – Integrity and Availability of ICT Systems
Control ID: Article 9 — ICT Security Policies and Procedures
CISA Zero Trust Maturity Model 2.0 – Continuous Authorization Validation for Applications
Control ID: Application Pillar — Application Security (Authorization)
NIS2 Directive (EU 2022/2555) – Security in Software Supply Chain and Development Practices
Control ID: Article 21(2)(e) — Supply Chain Security
ISO/IEC 27001:2022 – Secure Configuration and Key Management for Services
Control ID: Annex A 8.9 — Configuration Management
Sector Implications
Sector ImplicationsIndustry-specific impact of the vulnerabilities, including operational, regulatory, and cloud security risks.
Information Technology/IT
Critical Red Hat Quay CVEs (CVSS 9.8/9.9) enable container registry compromise, allowing attackers to overwrite CI/CD pipeline images, steal robot credentials, and propagate malicious containers across IT infrastructure via supply-chain injection.
Computer Software/Engineering
Supply-chain container registry compromise via CVE-2026-123710 allows unsigned key injection and image overwrites, enabling malicious code propagation through software build pipelines and OpenShift-integrated development environments without privilege escalation.
Computer/Network Security
Zero Trust segmentation and egress policy gaps exposed as Quay key-server logic flaws bypass authentication controls, undermining namespace trust boundaries, NIST.800-53.AC-6 compliance, and ZTMM identity-based policy enforcement across registry infrastructure.
Financial Services
Container registry compromise enabling credential theft and malicious image injection threatens PCI.4.0 compliance, with lateral movement risks across containerized financial workloads and exposure of secrets stored within private repository images.
Sources
Sources- Critical Red Hat Quay Flaw Lets Attackers Read and Overwrite All Private Container Images in a Registryhttps://thehackernews.com/2026/11/critical-red-hat-quay-flaw-lets.htmlVerified
- Red Hat CVE Advisory: CVE-2026-123710https://access.redhat.com/security/cve/cve-2026-123710Verified
- Red Hat CVE Advisory: CVE-2026-110697https://access.redhat.com/security/cve/cve-2026-110697Verified
- Red Hat Bugzilla: CVE-2026-123710 Bug Reporthttps://bugzilla.redhat.com/show_bug.cgi?id=2568072Verified
- Red Hat Solutions: Key Remediation for Quay CVE-2026-123710https://access.redhat.com/solutions/7149923Verified
- Upstream Quay Fix Commit (GitHub): Key rotation check and robot account search patchhttps://github.com/quay/quay/commit/094cfb024f01Verified
Frequently Asked Questions
Frequently Asked QuestionsCloud Native Security Fabric Mitigations and ControlsCNSF
Based on the attack progression modeled above, these are the defensive controls that would constrain each stage.
Aviatrix Zero Trust CNSF is directly relevant to this incident because the attacker relied on unrestricted network reachability to Quay's public endpoints and unconstrained east-west access across tenant namespaces and CI/CD infrastructure. By enforcing workload-level segmentation and controlled egress, CNSF would likely have reduced the attacker's ability to traverse tenant boundaries and exfiltrate container images at scale.
Control: Cloud Native Security Fabric (CNSF)
Mitigation: Restricting network access to Quay's key management and authentication endpoints at the fabric level could limit which source workloads and external principals are even able to reach those surfaces, reducing the pool of potential exploiters to only explicitly permitted identities and workload segments.
Control: Zero Trust Segmentation
Mitigation: Zero Trust segmentation could reduce the scope of privilege escalation by constraining which workloads and network paths are permitted to invoke administrative registry APIs and cross-tenant endpoints, limiting how far forged credentials could be exercised even if authentication controls at the application layer were bypassed.
Control: East-West Traffic Security
Mitigation: East-west traffic enforcement could limit the attacker's ability to pivot freely across tenant namespaces and into connected CI/CD infrastructure, reducing lateral reachability even when application-layer credentials had been stolen, by requiring that all inter-workload communication conform to defined and monitored segmentation policies.
Control: Multicloud Visibility & Control
Mitigation: Centralized multicloud visibility across registry API traffic could help reduce the attacker's ability to operate undetected over extended periods, by surfacing anomalous API call patterns — such as unexpected key registration or bulk key deletion events — that deviate from established behavioral baselines for registry workloads.
Control: Egress Security & Policy Enforcement
Mitigation: Egress security controls enforced at the fabric level could reduce the attacker's ability to exfiltrate large volumes of container images to unauthorized destinations, by limiting outbound registry pull traffic to known and approved egress paths and constraining the data volume and destination scope accessible from compromised workload identities.
If prior CNSF controls had constrained the attacker's lateral reach and egress paths, the residual impact would likely be reduced in scope — poisoned images may have reached fewer downstream clusters and pipelines, and the supply-chain compromise would likely be limited to the specific tenant segments that the attacker was able to access rather than propagating across all organizational boundaries.
Impact at a Glance
Affected Business Functions
- Container Image Distribution and CI/CD Pipeline Integrity
- Software Supply Chain Security
- Multi-Tenant Registry and Robot Account Management
- OpenShift Platform Operations and Deployment Automation
Estimated downtime: 7 days
Estimated loss: N/A
All private container images stored in affected Quay registries are exposed to unauthorized read access, potentially leaking embedded secrets, API keys, credentials, and proprietary application code stored within image layers. Robot account tokens for all tenants in a multi-tenant Quay deployment can be stolen and used to inject malicious images into CI/CD pipelines, enabling downstream supply-chain compromise across any organization or OpenShift cluster relying on the affected registry. Planted trusted keys persist across restarts and password resets, meaning unauthorized access may persist silently until keys are manually audited and removed. Organizations using Quay as the integrated OpenShift registry face cascading risk of malicious image propagation to production workloads.
Recommended Actions
Key Takeaways & Next Steps
- • Apply Zero Trust Segmentation (CNSF) to restrict access to Quay's /keys and /v2/auth endpoints to only verified, identity-authenticated internal components — preventing unauthenticated or low-privilege actors from interacting with key management APIs entirely, directly blocking CVE-2026-123710 exploitation.
- • Deploy Egress Security & Policy Enforcement controls to monitor and rate-limit container image pull volumes from the registry, flagging anomalous bulk pulls to unauthorized or unexpected destinations as indicators of image exfiltration using forged or stolen robot tokens.
- • Leverage Multicloud Visibility & Control to baseline normal registry API interaction patterns — including key rotation events, robot account listing calls, and cross-namespace access — and generate alerts on service_key_rotate or service_key_delete events where expiration_date is null, enabling early detection of persistent key injection.
- • Enforce East-West Traffic Security policies to segment registry access between tenants and namespaces, ensuring that robot account credentials obtained in one namespace cannot be used to authenticate against repositories in separate organizational boundaries without explicit policy permit.
- • Utilize Encrypted Traffic (HPE) controls to ensure all registry traffic transiting hybrid or multi-cloud network paths is encrypted at line rate, and pair with Inline IPS (Suricata) signature rules targeting known Quay API abuse patterns and anomalous JWT audience/issuer fields to detect forged token usage before images are pulled or overwritten.
