CVE-2026-109194 in Quay
Summary
by MITRE • 10/12/2026
A flaw was found in Red Hat Quay. The build trigger management application programming interface (API) fails to verify whether a requested trigger belongs to the specified repository. An authenticated user with administrative access to any repository can view, modify, or permanently delete build triggers and associated write tokens of another repository if they know the victim trigger's universally unique identifier (UUID).
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability identified in Red Hat Quay represents a critical failure in object-level authorization controls within the build trigger management application programming interface. This flaw stems from an insecure direct object reference mechanism where the system fails to validate that the requested resource, specifically a build trigger, is actually owned by or associated with the repository context provided in the request parameters. In secure software design, when an API endpoint accepts identifiers for resources such as triggers, it must perform a secondary authorization check to ensure the authenticated user has explicit permissions over that specific resource instance, rather than relying solely on the presence of valid authentication credentials and general administrative rights within a broader scope. The absence of this verification allows an attacker who possesses knowledge of a target trigger's universally unique identifier to bypass intended access restrictions entirely.
An authenticated user with administrative privileges in any repository can exploit this logic error by crafting specific API requests that reference build triggers belonging to different repositories, provided the UUID is known or guessable. This capability extends beyond mere observation; the attacker can modify existing configurations and permanently delete critical automation pipelines associated with those triggers. Furthermore, because these actions may involve write tokens used for authenticating external services like CI/CD systems, their compromise could lead to further unauthorized access or manipulation of downstream deployment processes. The impact is severe as it undermines the isolation boundaries between distinct repositories within a multi-tenant environment, allowing lateral movement and potential disruption of continuous integration workflows across unrelated projects.
From a classification perspective, this vulnerability aligns with CWE-639, which describes Authorization Bypass Through User-Controlled Key, specifically involving direct object references that are not properly validated against the current user's permissions. In terms of offensive security frameworks, this behavior maps to ATT&CK technique T1078, Valid Accounts, where an attacker uses legitimate credentials but exploits flawed authorization logic to access resources outside their intended scope. It also relates to T1530, Data from Cloud Storage Object Exfiltration or Modification if the triggers involve sensitive configuration data stored remotely. The core issue is not a lack of authentication but rather a deficiency in fine-grained access control enforcement at the API level.
Mitigation strategies must focus on implementing robust server-side validation for all resource identifiers received via API endpoints. Developers should ensure that every request to modify or delete a build trigger includes a verification step that confirms the triggering entity belongs exclusively to the repository associated with the authenticated session's administrative privileges. This involves querying the database or internal state management system to verify ownership before executing any destructive operations. Additionally, implementing rate limiting and logging for API calls involving sensitive identifiers can aid in detecting potential enumeration attempts where attackers probe for valid UUIDs. Red Hat Quay administrators should apply available patches that address this authorization bypass immediately to restore proper isolation between repositories and prevent unauthorized manipulation of build infrastructure.