CVE-2026-109195 in Quay
Summary
by MITRE • 10/12/2026
A flaw was found in Quay. An authenticated attacker can access repository auto-prune configurations from other namespaces, leading to unauthorized information disclosure. This issue occurs because the application does not properly enforce namespace scoping when retrieving policy details by repository name and policy identifier. To exploit the vulnerability, the attacker must manage a repository sharing the target's name and know the target policy's unique identifier.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/12/2026
The identified vulnerability in Quay represents a critical failure in multi-tenant isolation mechanisms within container registry infrastructure. As an authenticated user with access to the platform, an adversary can bypass namespace boundaries to retrieve sensitive configuration data belonging to other tenants or organizational units. This flaw specifically targets the repository auto-prune configurations, which dictate how old images are automatically removed from storage based on defined policies. The core technical deficiency lies in the application's logic for retrieving policy details; it relies primarily on a combination of the repository name and a specific policy identifier without adequately validating that these resources belong to the authenticated user's current namespace or project scope. This lack of strict scoping enforcement allows an attacker to construct requests that target policies outside their authorized domain, effectively treating the registry as if it were a single-tenant environment rather than enforcing strict logical separation between distinct namespaces.
From a technical perspective, this vulnerability is classified under CWE-284, which describes Improper Access Control, and more specifically aligns with CWE-601, URL Redirection to Untrusted Site or in the context of internal resource access, it reflects a failure in object level authorization checks. The exploitation vector requires two specific conditions: first, the attacker must manage a repository that shares an identical name with a target repository located in a different namespace; second, the attacker must possess knowledge of the unique identifier associated with the target's auto-prune policy. This suggests that while the system may use names for display or basic routing, it fails to bind these identifiers securely to their respective namespaces during the retrieval operation. Consequently, if an attacker can guess or discover a valid policy ID and create a repository with a matching name in their own namespace, they can trick the backend into returning configuration data intended for another entity. This is particularly dangerous because auto-prune policies often contain metadata about retention periods, storage quotas, and potentially integration points with external systems, all of which constitute sensitive operational intelligence.
The operational impact of this information disclosure extends beyond simple data leakage. By accessing these configurations, an attacker gains insight into the lifecycle management strategies of other tenants or departments within the organization. This knowledge can facilitate more targeted attacks against those namespaces. For instance, understanding when and how images are pruned allows an adversary to time their own activities to avoid detection during cleanup windows or to exploit known gaps in retention policies that might leave certain vulnerable artifacts accessible for longer than intended. Furthermore, this exposure violates fundamental principles of multi-tenancy security, potentially leading to compliance violations if the registry handles regulated data where strict isolation is mandated by standards such as ISO 27001 or SOC 2 Type II. The ability to enumerate and read configurations across namespaces undermines trust in the platform's integrity and could be leveraged for further privilege escalation attempts if other related endpoints share similar flaws.
To mitigate this vulnerability, immediate remediation should focus on enforcing strict namespace scoping at the application logic level whenever policy details are retrieved. Developers must ensure that every request to fetch repository or policy information explicitly validates that the requesting user has ownership or appropriate permissions within the specific namespace associated with the target resource. This involves binding the namespace context to both the repository name and the policy identifier, ensuring they originate from the same logical boundary before returning any data. Additionally, implementing robust input validation and rejecting requests where the resolved namespace does not match the authenticated user's scope is essential. From a defensive standpoint, organizations should also audit their Quay deployments for similar patterns in other API endpoints that handle resource retrieval by name or ID without sufficient contextual verification. Regular security assessments focusing on object-level authorization flaws are recommended to identify and patch such gaps before they can be exploited in production environments.