Red Hat Quay Container Registry Flaws: Two Critical CVEs Enable Full Image Supply-Chain Compromise

As reported by The Hacker News, Red Hat has disclosed two critical vulnerabilities in its Quay container registry platform that fundamentally undermine the integrity and confidentiality of every image stored within affected deployments. These flaws are not subtle edge-case bugs—they strike at the core trust model that Quay uses to authenticate image pushes and pulls, and the second flaw enables cross-tenant credential theft in multi-tenant environments.

Vulnerability Summary

Why This Matters

The first vulnerability (CVE-2026-123710) is particularly damaging because it exploits a logic flaw present since Quay's first public commit. The trust key server accepts tokens for key rotation without verifying that the token was actually issued for that purpose—any anonymous token from the /v2/auth endpoint suffices. An attacker can inject a persistent signing key that survives restarts, granting them carte blanche to read any private image (including embedded secrets) or overwrite images that downstream systems will later pull. Worse, they can delete legitimate keys, causing a denial-of-service for the entire registry.

The default-enabled anonymous access setting widens the blast radius considerably: an attacker with network access to the registry API requires no credentials at all to exploit CVE-2026-123710. Even with anonymous access disabled, any authenticated user—regardless of privilege level—can perform the attack.

CVE-2026-110697 is a textbook SQL LIKE wildcard injection. By creating a namespace with an underscore in a strategic position, an attacker can match another tenant's namespace pattern and retrieve decrypted robot account tokens. In OpenShift environments where Quay serves as the integrated registry, this opens a direct path to injecting malicious images into CI/CD pipelines—a supply-chain attack vector with cascading downstream impact.

These vulnerabilities turn the container registry from a storage artifact into an active attack surface. Any organization running Quay as the backbone of its container delivery pipeline should treat this as a P1 incident.

Who Is at Risk

• Highest risk: Organizations running Quay with anonymous access enabled (the default) and any unpatched version of Quay 3 or Quay 5.
• High risk: Multi-tenant Quay deployments where namespace isolation is relied upon for tenant separation—CVE-2026-110697 breaks that boundary entirely.
• High risk: OpenShift environments using Quay as the integrated registry, where stolen robot tokens can poison CI/CD pipelines.
• Moderate risk: Quay deployments with anonymous access disabled and strict RBAC, where exploitation requires at least one valid account.

Shield53 Recommendations

• Patch immediately. Upgrade to the latest fixed builds for your Quay 3 branch or Quay 5. Red Hat has released fixes across eight branches—identify your version and apply the corresponding build without delay.
• Disable anonymous access on all Quay registries, even if you plan to patch shortly. This eliminates the zero-authentication attack path for CVE-2026-123710.
• Audit trust keys. After patching, inspect Quay's key server for any unauthorized signing keys that may have been planted during the exposure window. Remove any unrecognized keys and rotate all signing keys.
• Review image integrity. For high-value registries, compare current image digests against known-good baselines (CI records, SBOMs, or signature logs) to detect tampering during the exposure period.
• Rotate robot account tokens across all namespaces, particularly in multi-tenant environments. Any token exposed during the vulnerability window must be considered compromised.
• Hunt for IOC. Look for unusual /v2/auth requests, unexpected key rotation API calls, and anomalous image pull/push patterns from unfamiliar sources or at unusual times.
• Network segmentation. Ensure Quay registries are not exposed to untrusted networks. Restrict API access to known CI/CD and developer subnets.

Given that CVE-2026-123710's logic has existed since Quay's first commit, organizations should assume that any Quay deployment that has ever been accessible to untrusted users may have been compromised. Treat this as a potential breach, not just a patch event—forensic review of signing keys and image integrity is essential, not optional.