CVE-2026-123710 in Quay
Summary
by MITRE • 11/11/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/11/2026
The vulnerability in Red Hat Quay represents a critical authentication bypass mechanism rooted in the improper validation of audience claims within registry token requests. An unauthenticated attacker can exploit this flaw by crafting specific HTTP requests that leverage weaknesses in how the service handles anonymous access to generate tokens. Specifically, the system allows an external party to obtain an anonymous registry token where the audience parameter is not strictly validated against expected internal services or scopes. This oversight enables the client to specify a custom audience value within the token structure, effectively manipulating the context under which subsequent operations are authorized by the Quay infrastructure.
Once this manipulated token is acquired, it can be presented to the service key rotation endpoint without requiring prior authentication for that specific action. The core technical flaw lies in the insufficient verification of permissions associated with the anonymous token when interacting with cryptographic management functions. By submitting a request containing their own public signing key alongside the forged audience claim, an attacker successfully registers this new key as an approved signing authority within the Quay instance. Crucially, the system fails to enforce expiration policies on keys installed through this specific endpoint during the exploitation window, resulting in the installation of a permanent, non-expiring signing key controlled entirely by the adversary.
The operational impact of this vulnerability is severe and comprehensive, granting full control over container image repositories that rely on signature verification for integrity assurance. Registry tokens signed with the attacker-controlled private key are subsequently accepted as valid across any repository within the affected Quay instance. This capability allows the malicious actor to perform both read and write operations without restriction. They can inspect sensitive proprietary images stored in private repositories, exfiltrating intellectual property or source code artifacts. More dangerously, they possess the ability to replace existing repository tags with compromised image layers that have been signed using their own key pair.
This level of access facilitates sophisticated supply chain attacks where malicious containers are pushed into production environments under the guise of legitimate updates. Since downstream systems and CI/CD pipelines typically trust images verified by authorized signing keys, the introduction of attacker-signed content bypasses these security controls entirely. Organizations relying on Quay for secure container distribution face significant risks including data leakage, unauthorized code execution in their infrastructure, and potential compromise of dependent services that pull from the affected repositories. The permanence of the installed key ensures persistent access even if initial authentication mechanisms are hardened or rotated later.
Mitigation strategies must focus on immediate remediation through software updates provided by Red Hat Quay maintainers to address the validation logic flaws. Administrators should verify whether any unauthorized signing keys have been added to their instances and rotate all existing cryptographic keys immediately upon patching. It is also advisable to audit access logs for anomalous requests targeting key rotation endpoints, particularly those originating from unauthenticated sources or containing unusual audience claims. Implementing stricter input validation on token generation services and enforcing expiration policies on all newly registered signing keys will help prevent similar exploitation vectors in future versions of the platform.