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.

An issue in Hyper on macOS version 3.4.1 and before, allows remote attackers to execute arbitrary code via the RunAsNode and enableNodeClilnspectArguments settings.

Impact It is possible to bypass authorization checks within a Next.js application, if the authorization check occurs in middleware.

Patches For Next.js 15.x, this issue is fixed in 15.2.3 For Next.js 14.x, this issue is fixed in 14.2.25 For Next.js 13.x, this issue is fixed in 13.5.9 For Next.js 12.x, this issue is fixed in 12.3.5 For Next.js 11.x, consult the below workaround.

Note: Next.js deployments hosted on Vercel are automatically protected against this vulnerability.

Workaround If patching to a safe version is infeasible, it is recommend that you prevent external user requests which contain the x-middleware-subrequest header from reaching your Next.js application.

Credits

- Allam Rachid (zhero;) - Allam Yasser (inzo)

Impact

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.

Fix

We now apply the same safety checks to WebSocket upgrade handling that already existed for normal HTTP requests, so upgrade requests are only proxied when routing has explicitly marked them as safe external rewrites.

Workarounds

If you cannot upgrade immediately, do not expose the origin server directly to untrusted networks. If WebSocket upgrades are not required, block them at your reverse proxy or load balancer, and restrict origin egress to internal networks and metadata services where possible.

Turborepo is a high-performance build system for JavaScript and TypeScript codebases. Prior to 2.9.14000, the Turborepo LSP VS Code extension could execute shell commands derived from workspace-controlled values. The extension used string-based command execution for Turborepo daemon commands and task runs. A malicious workspace could provide crafted values through workspace settings or task names in the repository's source code that were interpolated into shell commands. When the extension activated or when a user ran a task through the extension, those values could be interpreted by the user's shell, allowing arbitrary command execution with the privileges of the local VS Code process. This vulnerability is fixed in 2.9.14000.

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

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 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 NEXTPRIVATEORIGIN environment variable to your deployment's real origin:

bash NEXTPRIVATEORIGIN=https://www.example.com node server.js

A vulnerability in Next.js Middleware has been fixed in v14.2.32 and v15.4.7. The issue occurred when request headers were directly passed into NextResponse.next(). In self-hosted applications, this could allow Server-Side Request Forgery (SSRF) if certain sensitive headers from the incoming request were reflected back into the response.

All users implementing custom middleware logic in self-hosted environments are strongly encouraged to upgrade and verify correct usage of the next() function.

More details at Vercel Changelog

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.

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.

Impact Any native code packages built by pkg are written to a hardcoded directory. On unix systems, this is /tmp/pkg/ which is a shared directory for all users on the same local system. There is no uniqueness to the package names within this directory, they are predictable.

An attacker who has access to the same local system has the ability to replace the genuine executables in the shared directory with malicious executables of the same name. A user may then run the malicious executable without realising it has been modified.

Patches This package is deprecated. Therefore, there will not be a patch provided for this vulnerability.

Recommended Action: To check if your executable build by pkg depends on native code and is vulnerable, run the executable and check if /tmp/pkg/ was created.

Users should transition to actively maintained alternatives. We would recommend investigating Node.js 21’s support for single executable applications.

Workarounds Given the decision to deprecate the pkg package, there are no official workarounds or remediations provided by our team. Users should prioritize migrating to other packages that offer similar functionality with enhanced security.

The ms package before 0.7.1 for Node.js allows attackers to cause a denial of service (CPU consumption) via a long version string, aka a "regular expression denial of service (ReDoS)."

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

Impact A Server-Side Request Forgery (SSRF) vulnerability was identified in Next.js Server Actions by security researchers at Assetnote. If the Host header is modified, and the below conditions are also met, an attacker may be able to make requests that appear to be originating from the Next.js application server itself.

Prerequisites Next.js (<14.1.1) is running in a self-hosted manner. The Next.js application makes use of Server Actions. The Server Action performs a redirect to a relative path which starts with a /.

\ Many hosting providers (including Vercel) route requests based on the Host header, so we do not believe that this vulnerability affects any Next.js applications where routing is done in this manner.

Patches This vulnerability was patched in #62561 and fixed in Next.js 14.1.1. Workarounds There are no official workarounds for this vulnerability. We recommend upgrading to Next.js 14.1.1.

Credit Vercel and the Next.js team thank Assetnote for responsibly disclosing this issue to us, and for working with us to verify the fix. Thanks to:

Adam Kues - Assetnote Shubham Shah - Assetnote

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

Impact

By sending a crafted HTTP request, it is possible to poison the cache of a non-dynamic server-side rendered route in the pages router (this does not affect the app router). When this crafted request is sent it could coerce Next.js to cache a route that is meant to not be cached and send a Cache-Control: s-maxage=1, stale-while-revalidate header which some upstream CDNs may cache as well.

To be potentially affected all of the following must apply:

- Next.js between 13.5.1 and 14.2.9 - Using pages router - Using non-dynamic server-side rendered routes e.g. pages/dashboard.tsx not pages/blog/[slug].tsx

The below configurations are unaffected:

- Deployments using only app router - Deployments on Vercel are not affected

Patches

This vulnerability was resolved in Next.js v13.5.7, v14.2.10, and later. We recommend upgrading regardless of whether you can reproduce the issue or not.

Workarounds

There are no official or recommended workarounds for this issue, we recommend that users patch to a safe version.

Credits

- Allam Rachid (zhero) - Henry Chen

Impact The image optimization feature of Next.js contained a vulnerability which allowed for a potential Denial of Service (DoS) condition which could lead to excessive CPU consumption.

Not affected: - The next.config.js file is configured with images.unoptimized set to true or images.loader set to a non-default value. - The Next.js application is hosted on Vercel.

Patches This issue was fully patched in Next.js 14.2.7. We recommend that users upgrade to at least this version.

Workarounds Ensure that the next.config.js file has either images.unoptimized, images.loader or images.loaderFile assigned.

Credits Brandon Dahler (brandondahler), AWS Dimitrios Vlastaras

Impact If a Next.js application is performing authorization in middleware based on pathname, it was possible for this authorization to be bypassed.

Patches This issue was patched in Next.js 14.2.15 and later.

If your Next.js application is hosted on Vercel, this vulnerability has been automatically mitigated, regardless of Next.js version.

Workarounds There are no official workarounds for this vulnerability.

Credits We'd like to thank tyage (GMO CyberSecurity by IERAE) for responsible disclosure of this issue.

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)

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.

Impact

It was found that the fix to address CVE-2025-55184 in React Server Components was incomplete and does not prevent a denial of service attack in a specific case.

We recommend updating immediately.

The vulnerability exists in versions 19.0.2, 19.1.3, and 19.2.2 of:

- react-server-dom-webpack - react-server-dom-parcel - react-server-dom-turbopack

These issues are present in the patches published on December 11th, 2025.

Patches

Fixes were back ported to versions 19.0.3, 19.1.4, and 19.2.3.

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.

A denial of service vulnerability exists in Next.js versions with Partial Prerendering (PPR) enabled when running in minimal mode. The PPR resume endpoint accepts unauthenticated POST requests with the Next-Resume: 1 header and processes attacker-controlled postponed state data. Two closely related vulnerabilities allow an attacker to crash the server process through memory exhaustion:

1. Unbounded request body buffering: The server buffers the entire POST request body into memory using Buffer.concat() without enforcing any size limit, allowing arbitrarily large payloads to exhaust available memory.

2. Unbounded decompression (zipbomb): The resume data cache is decompressed using inflateSync() without limiting the decompressed output size. A small compressed payload can expand to hundreds of megabytes or gigabytes, causing memory exhaustion.

Both attack vectors result in a fatal V8 out-of-memory error (FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory) causing the Node.js process to terminate. The zipbomb variant is particularly dangerous as it can bypass reverse proxy request size limits while still causing large memory allocation on the server.

To be affected you must have an application running with experimental.ppr: true or cacheComponents: true configured along with the NEXTPRIVATEMINIMALMODE=1 environment variable.

Strongly consider upgrading to 15.6.0-canary.61 or 16.1.5 to reduce risk and prevent availability issues in Next applications.

A denial of service vulnerability exists in self-hosted Next.js applications that have remotePatterns configured for the Image Optimizer. The image optimization endpoint (/next/image) loads external images entirely into memory without enforcing a maximum size limit, allowing an attacker to cause out-of-memory conditions by requesting optimization of arbitrarily large images. This vulnerability requires that remotePatterns is configured to allow image optimization from external domains and that the attacker can serve or control a large image on an allowed domain. Strongly consider upgrading to 15.5.10 or 16.1.5 to reduce risk and prevent availability issues in Next applications.

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.

Impact

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

- If you are using images.localPatterns, only the patterns in that array are impacted. - If you are using images.unoptimized: true, you are NOT impacted. - If you are using images.loader: 'custom', you are NOT impacted. - If you are using Vercel, you are NOT impacted.

Fix

We now apply response size limits consistently to internal image fetches, not just external ones, and fail oversized responses before they can exhaust process memory.

This can be adjusted using the images.maximumResponseBody configuration.

Workarounds

If you cannot upgrade immediately, avoid routing large local assets through /next/image, disable image optimization for large or untrusted local files, or block image optimization access to those assets at the edge.

You can disable using the images.localPatterns: [] configuration. This will still allow fetching remote images (which is not impacted).

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.

Impact

Applications using the Pages Router with i18n configured and middleware/proxy-based authorization can allow unauthorized access to protected page data through locale-less /next/data/<buildId>/<page>.json requests. In affected configurations, middleware does not run for the unprefixed data route, allowing an attacker to retrieve SSR JSON for protected pages without passing the intended authorization checks.

Fix The matcher logic was updated to perform the same match as it would on a non-i18n data route.

Workarounds

If you cannot upgrade immediately, enforce authorization in the page's server-side data path instead of relying solely on middleware.

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 is a React framework. In versions of Next.js prior to 12.0.5 or 11.1.3, invalid or malformed URLs could lead to a server crash. In order to be affected by this issue, the deployment must use Next.js versions above 11.1.0 and below 12.0.5, Node.js above 15.0.0, and next start or a custom server. Deployments on Vercel are not affected, along with similar environments where invalid requests are filtered before reaching Next.js. Versions 12.0.5 and 11.1.3 contain patches for this issue.