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.
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).
A flaw was found in Red Hat Quay. The build trigger management endpoints (GET, PUT, DELETE on /api/v1/repository/<repository>/trigger/<triggeruuid>) resolve the trigger object by its global UUID without verifying that the trigger belongs to the repository specified in the request URL. The requirerepoadmin decorator only authorizes the caller against the URL namespace/repository, not against the object a handler loads. As a result, any user who is admin of any repository can read another repository's build trigger configuration, disable it, or permanently delete it (along with its delegate write token) by supplying the target trigger's UUID. Exploitation requires knowledge of the victim trigger's random v4 UUID, which is not normally visible across organizations. The vulnerability is in endpoints/api/trigger.py, specifically the BuildTrigger class get/put/delete methods, which all call gettrigger(triggeruuid) - a UUID-only lookup with no repository/namespace scoping. The sibling endpoint BuildTriggerAnalyze.post already has the correct ownership check, confirming this is an oversight.
A flaw was found in Red Hat Quay. The repository auto-prune policy endpoint (GET on /api/v1/repository/<namespace>/<repository>/autoprunepolicy/<policyuuid>) resolves the policy using the repository name and policy UUID only, without scoping to the authorized namespace. Because repository names are not globally unique (every namespace may have a repository with the same name), a user who is admin of a repository named X in their own namespace can read the auto-prune policy of a repository named X in another namespace by supplying that policy's UUID. The vulnerability is in data/model/autoprune.py in the getrepositoryautoprunepolicybyuuid function, which queries by Repository.name and UUID but never joins to the User table to enforce namespace scoping. The sibling function getrepositoryautoprunepoliciesbyreponame correctly scopes by namespace. The PUT and DELETE methods for the same resource are not affected because their model queries are namespace-scoped. Exploitation requires knowledge of the victim policy's random v4 UUID and a repository with a matching name. The leaked data is limited to low-sensitivity policy configuration (prune method, value, tag pattern).
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.
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.
A DOM-based cross-site scripting flaw was found in Project Quay's signin page (Signin.tsx). After a user completes a successful direct database login, the component reads the redirecturl query parameter and assigns it to window.location.href without validating the URL scheme or origin. An attacker can set redirecturl to a javascript: URI, causing arbitrary JavaScript execution in the authenticated Quay session after login. Exploitation requires the target deployment to use database authentication and the user to successfully authenticate through the crafted URL.
A DOM-based cross-site scripting (XSS) flaw was found in Project Quay's OAuth local callback handler (OAuthLocalHandler.tsx). When the format=json query parameter is supplied, the component reads the accesstoken from the URL fragment and assigns it to document.body.innerHTML via JSON.stringify, which does not HTML-encode angle brackets. An attacker can craft a URL containing a malicious accesstoken in the fragment that, when clicked by a Quay user, executes arbitrary JavaScript in the Quay registry origin. The format=json code path bypasses OAuth state validation and requires no authentication.
Webhook notification SSRF: hostname-string blocklist trivially bypassable
CWEs: CWE-918 CVSS: 6.4 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N) Component: quay/quay
Description HOSTNAMEBLACKLIST = ["localhost", "127.0.0.1"] extended by WEBHOOKHOSTNAMEBLACKLIST (default [], config.py:840). WebhookMethod.validate() and .perform() test only urlparse(url).hostname.lower() in HOSTNAMEBLACKLIST before requests.post(url, ...). No DNS resolution, no IP-range check, no use of util/security/ssrf.py. Any repo admin (i.e. any authenticated tenant on their own repo) can target 169.254.169.254, 0.0.0.0, [::1], 127.0.0.2, decimal/octal IP encodings, or an attacker DNS name resolving to RFC1918/link-local. Response body is logged on non-2xx (resp.content), giving a partial oracle.
Impact: blind/semi-blind POST SSRF to cloud-metadata and in-cluster services from the Quay pod network namespace.
Affected Locations - notifications/notificationmethod.py:22-23,213,236,253
Attack Pattern A repo admin configures a webhook notification pointing at an internal/metadata address using an encoding that evades the hostname string blocklist, causing the Quay pod to issue an authenticated-context POST to that internal target and expose limited response information via logged non-2xx bodies.
Remediation Route all webhook target validation through util/security/ssrf.py (DNS resolution + IP-range blocklist, not hostname string matching), consistent with the proxy-cache and mirror validators.
Note This finding shares its root cause class (missing SSRF validation in notifications/proxy/workers/repomirrorworker) with CVE-2026-32591 (already public, fixed). The CVSS vector/score above was computed independently -- the original audit did not provide one.
--- Source: Ex-Wing security assessment, finding QUAY-001
Webhook notification SSRF: hostname-string blocklist trivially bypassable
CWEs: CWE-918 CVSS: 6.4 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N) Component: quay/quay
Description HOSTNAMEBLACKLIST = ["localhost", "127.0.0.1"] extended by WEBHOOKHOSTNAMEBLACKLIST (default [], config.py:840). WebhookMethod.validate() and .perform() test only urlparse(url).hostname.lower() in HOSTNAMEBLACKLIST before requests.post(url, ...). No DNS resolution, no IP-range check, no use of util/security/ssrf.py. Any repo admin (i.e. any authenticated tenant on their own repo) can target 169.254.169.254, 0.0.0.0, [::1], 127.0.0.2, decimal/octal IP encodings, or an attacker DNS name resolving to RFC1918/link-local. Response body is logged on non-2xx (resp.content), giving a partial oracle.
Impact: blind/semi-blind POST SSRF to cloud-metadata and in-cluster services from the Quay pod network namespace.
Affected Locations - notifications/notificationmethod.py:22-23,213,236,253
Attack Pattern A repo admin configures a webhook notification pointing at an internal/metadata address using an encoding that evades the hostname string blocklist, causing the Quay pod to issue an authenticated-context POST to that internal target and expose limited response information via logged non-2xx bodies.
Remediation Route all webhook target validation through util/security/ssrf.py (DNS resolution + IP-range blocklist, not hostname string matching), consistent with the proxy-cache and mirror validators.
Note This finding shares its root cause class (missing SSRF validation in notifications/proxy/workers/repomirrorworker) with CVE-2026-32591 (already public, fixed). The CVSS vector/score above was computed independently -- the original audit did not provide one.
--- Source: Ex-Wing security assessment, finding QUAY-001
A flaw was found in Red Hat Quay's Stripe billing webhook handler. The /webhooks/stripe endpoint at endpoints/webhooks.py accepts incoming JSON requests without validating the Stripe-Signature header, allowing an unauthenticated attacker to forge billing events. The endpoint is registered unconditionally, even when FEATUREBILLING is disabled. An attacker can forge charge.succeeded events to reset a namespace's build quota to the server-configured maximum and trigger unsolicited billing emails (invoice, payment-failed, subscription-change) to namespace administrators. The checkout.session.completed path calls stripe.SetupIntent.retrieve with attacker-controlled IDs, but subsequent mutations use values from Stripe's response rather than the attacker's payload. Impact is Medium-High for quay.io deployments with real Stripe integration and Low for self-hosted defaults using FakeStripe.
A flaw was found in Red Hat Quay's exported logs feature. An unauthenticated attacker with a valid file ID could download exported action logs without proper authorization. While file IDs are complex, they can be intercepted from plaintext email or webhook callbacks. This vulnerability leads to information disclosure, potentially exposing sensitive data such as usernames, email addresses, IP addresses, and action-specific metadata.
A flaw was found in Red Hat Quay. A user with FEATUREBUILDSUPPORT enabled and repository write access can exploit a Server-Side Request Forgery (SSRF) vulnerability within the build API. This allows the user to provide a malicious URL, causing the Quay builder to make requests to internal network addresses. Such an action could lead to the disclosure of sensitive internal information.
A flaw was found in Red Hat Quay's Stripe billing webhook handler. The /webhooks/stripe endpoint at endpoints/webhooks.py accepts incoming JSON requests without validating the Stripe-Signature header, allowing an unauthenticated attacker to forge billing events. The endpoint is registered unconditionally, even when FEATUREBILLING is disabled. An attacker can forge charge.succeeded events to reset a namespace's build quota to the server-configured maximum and trigger unsolicited billing emails (invoice, payment-failed, subscription-change) to namespace administrators. The checkout.session.completed path calls stripe.SetupIntent.retrieve with attacker-controlled IDs, but subsequent mutations use values from Stripe's response rather than the attacker's payload. Impact is Medium-High for quay.io deployments with real Stripe integration and Low for self-hosted defaults using FakeStripe.
A flaw was found in Red Hat Quay's exported logs feature. The /exportedlogs/<fileid> endpoint at endpoints/web.py:411 has no authentication decorator, allowing any caller with a valid file ID to download exported action logs without authentication. While the file ID is 256 bits (two UUID4s) making blind enumeration infeasible, the ID is delivered via plaintext email and webhook callbacks, creating interception opportunities. On cloud storage backends the download URL expires in 1 hour, but on LocalStorage backends exported log files persist indefinitely and the unauthenticated endpoint serves them with no time limit. Exported logs contain usernames, email addresses, IP addresses, action types, and action-specific metadata.
A flaw was found in Red Hat Quay's JWT (JSON Web Token) validation for federated robot accounts and single sign-on (SSO) authentication. Multiple issues related to audience verification and the enforcement of azp and sub claims were identified. These flaws could allow an attacker with a validly-signed token from the same identity provider to bypass configured security restrictions. This bypass could lead to unauthorized access by circumventing intended audience, subject, or authorized-client limitations.
A flaw was found in Red Hat Quay's external LDAP authentication handling. When an LDAP referral is returned during authentication, the referral handler at data/users/externalldap.py:700 constructs a search filter using the raw usernameoremail input without applying escapefilterchars(), unlike the normal authentication path which correctly escapes the input. This allows LDAP filter metacharacters (, (, )) in the username to be injected into the referral path's search filter. While SCOPEBASE limits the search to a single DN (preventing directory enumeration) and a separate simplebinds password check prevents direct authentication bypass, an attacker could use this to perform user-existence oracle attacks at the referral DN and potentially influence which DN enters the password bind in multi-domain Active Directory environments.
A flaw was found in Red Hat Quay. An administrator of any repository, by knowing or guessing a target notification's Universally Unique Identifier (UUID), can read the notification configuration, including sensitive details like webhook URLs, Slack tokens, and email addresses. This vulnerability also allows them to trigger test notifications for another repository. This could lead to unauthorized information disclosure and potential misuse of notification services.
A flaw was found in Red Hat Quay. When the SECURITYSCANNERV4PSK (pre-shared key) is not set, a remote unauthenticated attacker can send POST requests to the security scanner notification endpoint. This allows the attacker to flood the notification queue and inject path traversal characters into Clair API URL paths. The primary consequence is worker resource exhaustion and blind path manipulation on the configured Clair host, potentially leading to a denial of service.
A flaw was found in Red Hat Quay's external LDAP authentication handling. When an LDAP referral is returned during authentication, the referral handler at data/users/externalldap.py:700 constructs a search filter using the raw usernameoremail input without applying escapefilterchars(), unlike the normal authentication path which correctly escapes the input. This allows LDAP filter metacharacters (, (, )) in the username to be injected into the referral path's search filter. While SCOPEBASE limits the search to a single DN (preventing directory enumeration) and a separate simplebinds password check prevents direct authentication bypass, an attacker could use this to perform user-existence oracle attacks at the referral DN and potentially influence which DN enters the password bind in multi-domain Active Directory environments.
A flaw was found in Red Hat Quay's JWT token validation for federated robot accounts and SSO authentication. Three related issues were identified: (1) When no audiences are configured for federated robot authentication (the default), verifyaud is set to False, accepting any validly-signed token from the same IdP regardless of intended audience. (2) The OIDCALLOWEDCLIENTS / azp enforcement check in auth/oauth.py short-circuits when the azp claim is absent from the token (None), allowing tokens without an azp claim to bypass client restrictions. (3) Pre-existing federation configurations created before API validation enforcement (or written directly to the database) without a subject field allow tokens without a sub claim to match. These issues could allow an attacker with a validly-signed token from the same identity provider to bypass configured audience, subject, or authorized-client restrictions.
A flaw was found in Red Hat Quay's repository notification API endpoints. The GET and test-trigger endpoints in endpoints/api/repositorynotification.py look up notifications by UUID without verifying that the notification belongs to the repository specified in the URL path. An admin of any repository who knows or guesses a target notification's UUID can read the notification configuration (including webhook URLs, Slack tokens, and email addresses) and fire test notifications for another repository's notification. The DELETE and reset endpoints correctly scope by repository. Exploitation requires knowing a 128-bit notification UUID.
A flaw was found in Red Hat Quay's security scanner notification endpoint. When SECURITYSCANNERV4PSK is unset (the default configuration), the /secscan/notification endpoint at endpoints/secscan.py accepts anonymous POST requests with no authentication. An attacker can flood the secscan notification queue and inject notificationid values containing path traversal characters into Clair API URL paths. The impact is worker resource exhaustion and blind path manipulation on the configured Clair host. Operator-managed deployments auto-generate the PSK, limiting exposure to standalone installations that have not explicitly configured the pre-shared key.
A flaw was found in Red Hat Quay's notification webhook dispatch feature. The SlackMethod and WebhookMethod notification handlers in notifications/notificationmethod.py accept attacker-controlled URLs without applying the validateexternalregistryurl() SSRF validator that protects other Quay features (proxy cache, organization mirror, repository mirror). A repository administrator can create a notification whose delivery URL points to internal network addresses. When the notification fires, the Quay worker performs a POST request to the attacker-specified URL, enabling blind SSRF from the worker network context. The WebhookMethod includes a HOSTNAMEBLACKLIST check, but it only performs exact-hostname matching against a minimal default list (localhost, 127.0.0.1) and is trivially bypassed with private IP literals, cloud metadata hostnames, or DNS rebinding.
A flaw was found in Red Hat Quay's notification webhook dispatch feature. The SlackMethod and WebhookMethod notification handlers in notifications/notificationmethod.py accept attacker-controlled URLs without applying the validateexternalregistryurl() SSRF validator that protects other Quay features (proxy cache, organization mirror, repository mirror). A repository administrator can create a notification whose delivery URL points to internal network addresses. When the notification fires, the Quay worker performs a POST request to the attacker-specified URL, enabling blind SSRF from the worker network context. The WebhookMethod includes a HOSTNAMEBLACKLIST check, but it only performs exact-hostname matching against a minimal default list (localhost, 127.0.0.1) and is trivially bypassed with private IP literals, cloud metadata hostnames, or DNS rebinding.
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 externalreference parameter without SSRF validation, unlike the organization-level mirror handlers which apply validateexternalregistryurl(). 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.
A Server-Side Request Forgery (SSRF) vulnerability was identified in Red Hat Quay's repository-level mirror configuration feature. An authenticated repository administrator can supply an attacker-controlled hostname as the externalreference parameter when enabling or updating repository mirroring via endpoints/api/mirror.py (POST and PUT handlers). The value is stored without SSRF validation and later interpolated into a docker:// URL that Skopeo uses for HTTP requests, allowing the attacker to force the Quay mirror worker to connect to internal services.