Red Hat Quay EUVD-2026-46150

Exploitation requires an authenticated account with repository administrator privileges within Red Hat Quay - standard developer or read-only users cannot reach the vulnerable POST/PUT handlers for repository-level mirror configuration. The specific vulnerable code path is the mirror configuration endpoints in endpoints/api/mirror.py; the attacker must submit a mirror configuration payload containing a crafted external_reference value pointing to an internal or metadata destination. The Quay mirror worker must be running and must have network reachability to the targeted internal resource for the SSRF to yield useful data - if the worker is network-isolated, exploitation is limited. Organization-level mirror handlers are explicitly NOT affected (they apply validate_external_registry_url()). Exploitation is not possible by unauthenticated users or by users without repository administrator rights, which is the primary limiting factor beyond network topology.

The CVSS 3.1 base score of 6.8 (AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N) accurately reflects the asymmetry of this vulnerability: exploitation is straightforward once repository admin access is obtained (AC:L), but that access requirement (PR:H) meaningfully limits the attack surface. The scope change (S:C) and high confidentiality impact (C:H) are the most consequential signals - successful exploitation can expose cloud IAM credentials, internal API responses, or other secrets from services reachable only within the cluster network, making this a privilege-escalation stepping stone rather than a pure Quay data leak. In multi-tenant Quay deployments where repository admin rights are broadly delegated - a common pattern in CI/CD environments - the effective attacker population is larger than PR:H implies. No EPSS score or KEV listing is available in the provided data, and no public POC has been identified, suggesting this has not yet been operationally exploited. The combination of no active exploitation and a high-privilege prerequisite makes this a medium operational priority, but organizations running multi-tenant Quay or exposing Quay workers to cloud metadata services should treat it as high due to the potential credential-theft impact.

A repository administrator in a shared Red Hat Quay deployment creates or updates a repository mirror configuration via the API, setting external_reference to a URL targeting the AWS Instance Metadata Service (http://169.254.169.254/latest/meta-data/iam/security-credentials/). The Quay mirror worker passes this value to Skopeo, which initiates an outbound request to the metadata endpoint; if the Quay worker runs on an EC2 instance or within a cloud-hosted OpenShift cluster with IMDSv1 enabled, the response may return temporary IAM credentials that the attacker can use to escalate privileges within the cloud environment. No public POC has been identified, but the technique is well-understood and the attack path requires only standard Quay API knowledge.