Where
-Infinity
0
Severity
7.5
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N

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.

1 / 2
Source: Red Hat
First published (updated )
Severity
7.5
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

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.

1 / 2
Source: MITRE
First published (updated )
Severity
7.1
SSRF
AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N

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.

1 / 2
Source: MITRE
First published (updated )
Severity
4

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.

First published (updated )
Severity
4

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.

First published (updated )
Severity
5.4
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N

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.

1 / 2
Source: MITRE
First published (updated )
Severity
6.5
AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

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.

1 / 2
Source: Red Hat
First published (updated )
Severity
5.3
AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N

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.

1 / 2
Source: MITRE
First published (updated )
Severity
8.2
Path Traversal
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L

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.

1 / 2
Source: MITRE
First published (updated )
Severity
4

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.

First published (updated )
Severity
4

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.

First published (updated )
Severity
4

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.

First published (updated )
Severity
4
Path Traversal

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.

First published (updated )
Severity
7

Quay 3.12.21

1 / 2
Source: Red Hat
First published (updated )
Severity
7

Quay 3.9.25

1 / 2
Source: Red Hat
First published (updated )
Severity
7

Quay 3.18.0

1 / 2
Source: Red Hat
First published (updated )
Severity
5.5
SSRF
AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N

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.

1 / 2
Source: Red Hat
First published (updated )
Severity
4
SSRF

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.

First published (updated )
Severity
6.8
SSRF
AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N

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.

1 / 2
Source: MITRE
First published (updated )
Severity
7
SSRF

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.

First published (updated )
Severity
7

Red Hat Quay 3.15.5

First published (updated )
Severity
7

Red Hat Quay 3.17.3

First published (updated )
Severity
5.4
XSS, CSRF
AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N

A flaw was found in Quay. The filedrop endpoint accepts any mime type without validation, allowing an authenticated user with repository write access to upload a malicious SVG file containing JavaScript. The file is stored and served inline through the CDN, enabling stored cross-site scripting when a victim visits the archive URL.

1 / 2
Source: MITRE
First published (updated )
Severity
4
CSRF

The filedrop endpoint (POST /api/v1/filedrop/) accepts any mimeType without validation, including image/svg+xml, text/html, and application/javascript. An attacker with repository write access can upload a malicious SVG file containing JavaScript, create a build referencing the fileid, and obtain an archiveurl that serves the SVG through the CDN. When a victim visits the archive URL, the browser renders the SVG inline and executes the embedded JavaScript. The malicious SVG is stored in the object storage backend and served through a legitimate Quay domain. However, session hijacking is not possible as the csrftoken session cookie is configured with HttpOnly and Secure attributes.

First published (updated )
Severity
7

Red Hat Quay 3.9.22

Remedy

Before applying this update, make sure all previously released errata relevant<br>to your system have been applied.<br>For details on how to apply this update, refer to:<br><a href="https://access.redhat.com/articles/11258" target="_blank">https://access.redhat.com/articles/11258</a>
First published (updated )
Severity
4

A flaw was found in Red Hat Quay. When Quay requests password re-verification for sensitive operations (e.g., token generation, robot account creation) due to session timeout, the re-authentication prompt can be bypassed. Although the UI displays an error popup for invalid credentials, the sensitive operations are still successfully executed in the background. This allows a user whose session has timed out (or an attacker with access to an idle authenticated browser session) to perform privileged actions without providing valid credentials.

The vulnerability exists in both the old and new Quay UI. Some endpoints that require fresh authentication are affected (e.g., robot account creation, token generation) while others correctly enforce reauthentication (e.g., user creation).

Upstream reference: PROJQUAY-11274

First published (updated )
Severity
5.5
SSRF
AV:N/AC:L/PR:H/UI:R/S:U/C:H/I:L/A:N

A flaw was found in Red Hat Quay's Proxy Cache configuration feature. When an organization administrator configures an upstream registry for proxy caching, Quay makes a network connection to the specified registry hostname without verifying that it points to a legitimate external service. An attacker with organization administrator privileges could supply a crafted hostname to force the Quay server to make requests to internal network services, cloud infrastructure endpoints, or other resources that should not be accessible from the Quay application.

1 / 2
Source: NVD
First published (updated )
Severity
7
SSRF

A Server-Side Request Forgery (SSRF) vulnerability was identified in Red Hat Quay v3.12.x within the Proxy Cache configuration feature. An authenticated organization administrator can supply an attacker-controlled hostname as the upstreamregistry parameter when creating or validating a proxy cache configuration. Quay instantiates a network connection to the supplied hostname with no validation against internal address ranges, private IP space, or cloud metadata endpoints.

Requirements to exploit: Attacker needs to be logged into the web app / initiate podman execution from host.

Component affected: Mirror Registry for OpenShift – Proxy Cache configuration feature Quay deployed on OpenShift 4.20 – Proxy Cache configuration feature

Version affected: latest releases

First published (updated )

Quay 3.11.11

First published (updated )

Quay 3.14.2

First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203