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

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

Applications that use beforeInteractive scripts together with untrusted content can be vulnerable to cross-site scripting. In affected versions, serialized script content was not escaped safely before being embedded into the document, which could allow attacker-controlled input to break out of the intended script context and execute arbitrary JavaScript in a visitor's browser.

Fix

We now HTML-escape serialized beforeInteractive script content before embedding it into the page, preventing attacker-controlled content from breaking out of the inline script boundary.

Workarounds

If you cannot upgrade immediately, do not pass untrusted data into beforeInteractive scripts. If that pattern is unavoidable, sanitize or escape the content before embedding it.