CVE-2026-15927 in mirror registry for OpenShift
Summary
by MITRE • 07/21/2026
A flaw was found in Red Hat Quay's repository-level mirror configuration feature. The POST and PUT handlers in endpoints/api/mirror.py accept an external_reference parameter without SSRF validation, unlike the organization-level mirror handlers which apply validate_external_registry_url(). A repository administrator can supply a crafted hostname that causes the Quay mirror worker to make requests via Skopeo to internal network services, cloud metadata endpoints, or other resources not intended to be reachable from the Quay application.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/21/2026
This vulnerability exists within Red Hat Quay's repository-level mirror configuration functionality where the application fails to properly validate external references provided through API endpoints. The flaw specifically affects the POST and PUT handlers located in endpoints/api/mirror.py which process the external_reference parameter without implementing server-side request forgery validation mechanisms that are present at the organization level. While organization-level mirror handlers correctly utilize validate_external_registry_url() to sanitize external registry URLs, repository-level handlers omit this crucial security control, creating a path for malicious actors to exploit.
The technical implementation of this vulnerability stems from inconsistent security controls across different levels of Quay's API architecture. When a repository administrator configures a mirror using the affected endpoints, they can supply a crafted hostname value that bypasses normal network access restrictions. This allows the Quay mirror worker process to initiate outbound requests through Skopeo to internal network services, cloud metadata endpoints, or other sensitive resources that should remain isolated from external application access. The vulnerability essentially creates an unrestricted proxy mechanism within the Quay application that can be leveraged to probe internal networks and potentially exfiltrate information.
The operational impact of this vulnerability is significant as it enables remote attackers to perform internal network reconnaissance and potentially exploit other vulnerabilities present within the internal infrastructure. Attackers could leverage this flaw to access cloud metadata services such as AWS metadata endpoints, Azure instance metadata, or other internal services that typically should not be directly reachable from external applications. This represents a critical security gap that transforms a repository configuration feature into an unauthorized internal network access vector, potentially allowing for privilege escalation, data exfiltration, or further attack progression within the organization's network.
This vulnerability maps to CWE-918 Server-Side Request Forgery and aligns with ATT&CK technique T1071.004 Application Layer Protocol: DNS, though more specifically represents a service-to-service request forgery scenario. The flaw demonstrates poor input validation practices in API endpoint implementations where security controls are inconsistently applied across different architectural levels. Organizations using Red Hat Quay should immediately implement mitigations including restricting the external_reference parameter validation to match organization-level controls, implementing network segmentation to prevent internal service access from the Quay application environment, and conducting thorough network access reviews to identify potential unauthorized internal resource exposure. Additionally, monitoring for unusual outbound requests from Quay mirror workers and implementing proper API rate limiting can help detect exploitation attempts.