CVE-2026-105447: Quay: quay: global read-only superuser can access build trigger write credentials
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.
Other sources
A flaw was found in Quay's build trigger API endpoints. The BuildTriggerList.get and BuildTrigger.get handlers in endpoints/api/trigger.py hardcode canadmin=True when serializing trigger data via the triggerview function, regardless of whether the caller is a full administrator or a global read-only superuser. This causes the trigger configuration, including delegate write tokens embedded in webhook endpoint URLs, to be exposed to users in the GLOBALREADONLYSUPERUSERS list. These delegate tokens carry push scope for the repository and can be used to push arbitrary container images to private repositories, bypassing the read-only restriction of the caller's role.
— Red Hat
Affected Software
Event History
Frequently Asked Questions
Who can exploit this issue?
An authenticated user configured as a global read-only superuser can exploit it. The user must be able to query the build trigger API for a repository with a build trigger.
What access can an attacker gain through the exposed data?
The API response can expose delegate write tokens embedded in build-trigger webhook endpoint URLs. Those tokens have push scope for the affected repository and can be used to push arbitrary container images to private repositories.
How can administrators determine whether a user may have been exposed to this issue?
Review membership in the GLOBAL_READONLY_SUPER_USERS list and identify which of those users could query build trigger API endpoints. Repositories with build triggers are relevant because their trigger configuration can contain the delegate write tokens.
What should be prioritized if immediate remediation is not available?
Prioritize restricting global read-only superuser access to build trigger API data and protecting or rotating delegate write tokens associated with build triggers where possible. Treat tokens from potentially exposed trigger configurations as repository write credentials.