A memory-related vulnerability in an upstream library used by Next.js for Image Optimization can lead to unauthenticated remote code execution (RCE) when processing SVG files on glibc-based Linux systems. This affects Next.js versions from 10.0.0 up to but excluding 15.5.28, and from 16.0.0 up to but excluding 16.4.1. The vulnerability is critical and can be mitigated by upgrading the 'sharp' library to version 0.35.5 or later, which is included in patched Next.js releases.
Next.js versions from 15.0.0 up to but not including 15.5.27, and from 16.0.0 up to but not including 16.3.8, contain a vulnerability where a shared response cache key is insufficiently scoped. This allows an unauthenticated attacker to poison the cache via a crafted request, potentially causing cross-user content substitution or persistent denial of service until the cache entry is refreshed. The issue is fixed in versions 15.5.27 and 16.3.8.
Next.js is a React framework for building full-stack web applications. From 16.0.0 until 16.3.8, the `next dev` development server exposes a Model Context Protocol endpoint without reliably restricting cross-site requests. A malicious website visited by a developer can reach the endpoint and read the project's disk location, source code snippets from error reports, route inventory, and development logs. Production deployments do not serve this endpoint. This issue is fixed in version 16.3.8.
Next.js versions from 15.0.0 up to but not including 15.5.27, and from 16.0.0 up to but not including 16.3.8, contain a vulnerability where the response cache for statically generated or Incremental Static Regeneration pages using the Pages Router can be incorrectly keyed. This allows a request to replace one page's cached content with that of another route, causing incorrect content to be served to visitors until the cache is revalidated. Applications deployed on Vercel are not affected. The issue is fixed in versions 15.5.27 and 16.3.8.
Next.js is a React framework for building full-stack web applications. From 16.0.0 until 16.3.8, the next dev development server exposes a Model Context Protocol endpoint without reliably restricting cross-site requests. A malicious website visited by a developer can reach the endpoint and read the project's disk location, source code snippets from error reports, route inventory, and development logs. Production deployments do not serve this endpoint. This issue is fixed in version 16.3.8.
## Impact
When a Server Action forwards or redirects a request, an attacker can cause the server to send that outbound request to a malicious host (Server-Side Request Forgery). This requires the attacker's request to control Host-associated headers. In some configurations, it's also possible to obtain internal values that weaken middleware/proxy authorization.
Applications that use Server Actions are affected when the incoming host header is not fixed to a trusted value. This typically occurs on custom servers, or on deployments not behind a proxy that pins the host. Managed hosting pins the host upstream and is not affected; `next start` and standalone output do the same from version 14.2 onward.
## Workarounds
If you cannot upgrade, ensure clients do not control the host header your application receives. Pin or validate `Host` and `X-Forwarded-Host` at your edge or proxy. On version 14.2.0 and later, you can additionally set the `__NEXT_PRIVATE_ORIGIN` environment variable to your deployment's real origin:
```bash
__NEXT_PRIVATE_ORIGIN=https://www.example.com node server.js
## 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.
## 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.
## 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.
## 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-]+)'`.
### Impact
When self-hosting Next.js with the default image loader, the Image Optimization API can optimize remotely hosted images if configured (not enabled by default). If those images contain malicious content, they can cause CPU exhaustion in `/_next/image` endpoints.
- If you are using `config.images.remotePatterns`, only the patterns in that array are impacted.
- If you are using `config.images.unoptimized: true`, you are NOT impacted.
- If you are using `config.images.loader: 'custom'`, you are NOT impacted.
- If you are using Vercel, you are NOT impacted.
### Workarounds
If you cannot upgrade immediately, you can avoid the expensive work by setting `config.experimental.imgOptSkipMetadata : true`.
## 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.
## Impact
Crafted requests targeting Next.js applications using App Router built with Turbopack and a **single** entry in `config.i18n.locales` can bypass middleware/proxy based authentication.
## Workarounds
If you cannot upgrade immediately, enforce authorization in the page's server-side data path instead of relying solely on middleware.
## 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.
Next.js is a React framework for building full-stack web applications. From 13.4.6 to before 15.5.16 and 16.2.5, React Server Component responses can be vulnerable to cache poisoning in deployments that rely on shared caches with insufficient response partitioning. In affected conditions, collisions in the _rsc cache-busting value can allow an attacker to poison cache entries so users receive the wrong response variant for a given URL. This vulnerability is fixed in 15.5.16 and 16.2.5.
Next.js is a React framework for building full-stack web applications. From 13.4.0 to before 15.5.16 and 16.2.5, App Router applications that rely on CSP nonces can be vulnerable to stored cross-site scripting when deployed behind shared caches. In affected versions, malformed nonce values derived from request headers could be reflected into rendered HTML in an unsafe way, allowing an attacker to poison cached responses and cause script execution for later visitors. This vulnerability is fixed in 15.5.16 and 16.2.5.
Next.js is a React framework for building full-stack web applications. From to before 15.5.16 and 16.2.5, 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. This vulnerability is fixed in 15.5.16 and 16.2.5.
Next.js is a React framework for building full-stack web applications. From 13.4.13 to before 15.5.16 and 16.2.5, self-hosted applications using the built-in Node.js server can be vulnerable to server-side request forgery through crafted WebSocket upgrade requests. An attacker can cause the server to proxy requests to arbitrary internal or external destinations, which may expose internal services or cloud metadata endpoints. Vercel-hosted deployments are not affected. This vulnerability is fixed in 15.5.16 and 16.2.5.
Next.js is a React framework for building full-stack web applications. From 10.0.0 to before 15.5.16 and 16.2.5, when self-hosting Next.js with the default image loader, the Image Optimization API fetches local images entirely into memory without enforcing a maximum size limit. An attacker could cause out-of-memory conditions by requesting large local assets from the /_next/image endpoint that match the images.localPatterns configuration (by default, all patterns are allowed). This vulnerability is fixed in 15.5.16 and 16.2.5.
Next.js is a React framework for building full-stack web applications. From 14.2.0 to before 15.5.16 and 16.2.5, 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. This vulnerability is fixed in 15.5.16 and 16.2.5.