Description

A flaw was found in Quay. When handling build trigger requests, the application incorrectly exposes trigger configuration details containing repository write tokens to global read-only administrative users. An authenticated user with read-only privileges can exploit this flaw by querying the build trigger API to retrieve these delegate tokens. This issue allows a restricted user to bypass read-only limitations and push arbitrary container images to private repositories, leading to privilege escalation.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.5",
  "pubDate": "2026-10-05T21:16:34.650Z",
  "pubdate": "2026-10-05T21:16:34.650Z",
  "executiveSummary": "A critical security vulnerability has been identified in Quay involving the improper authorization of build trigger configuration data.\nThe flaw allows authenticated users with read-only administrative privileges to access sensitive repository write tokens that are inappropriately exposed through the build trigger API.\nBy retrieving these delegate tokens, a restricted user can circumvent established read-only access controls, enabling unauthorized write operations such as pushing arbitrary container images to private repositories.\nThe vulnerability represents a significant privilege escalation risk, as it effectively grants read-only users the ability to modify repository contents and compromise the integrity of the software supply chain.\nSuccessful exploitation requires the attacker to possess authenticated, read-only access to the Quay administrative interface and the capability to interact with the build trigger API endpoints.\nThe issue highlights a failure in the application's access control enforcement logic when processing configuration retrieval requests for build triggers.",
  "technicalDetails": "The root cause of this vulnerability lies in an improper access control check within the Quay build trigger subsystem. When the application processes requests for build trigger configurations, the backend API fails to filter sensitive information based on the requesting user's authorization level.\nSpecifically, the build trigger API incorrectly includes repository write tokens—intended for use by build delegates—in the JSON response provided to global read-only administrative users. Under normal conditions, these tokens should be scoped exclusively to authorized service accounts or users with write permissions for the respective repository.\nThe attack flow proceeds as follows: First, an attacker with read-only administrative credentials identifies the build trigger API endpoint. Second, the attacker issues a GET or similar request to the build trigger configuration endpoint for a target repository. Third, the Quay application, failing to enforce restrictive filtering on the response object, returns the full configuration object, which contains the cleartext repository write token.\nOnce the token is acquired, the attacker can leverage the token via the Quay API or registry protocol to perform actions outside the scope of their read-only privileges. This effectively bypasses the application's authorization framework, allowing the attacker to authenticate as an entity with write access to the private repository.\nThe post-exploitation impact is severe, as the attacker can push malicious or arbitrary container images into private registries. This facilitates software supply chain contamination, where compromised images could be pulled and executed in production environments. Furthermore, because the attacker is operating with the hijacked write token, these actions may bypass certain audit trails tied to the read-only user's original account, complicating incident response and forensics.\nThe vulnerability affects the build trigger handler component. Exploitation is limited to users who already possess read-only administrative access, meaning the primary exposure is from internal threats or compromised low-privilege administrative accounts."
}