Mitigate CVE-2025-29927 in Next.js

You can block requests that exploit CVE-2025-29927 from Azion Console, with one rule on Rules Engine for Applications that removes the header the exploit depends on.

CVE-2025-29927 is a vulnerability in Next.js, scored CVSS 9.1, that lets a request skip middleware execution. Next.js middleware commonly carries authentication, authorization, and rate limiting, so a request that skips it reaches protected routes with no credentials. The advisory record is GHSA-f82v-jwr5-mffw and in the Next.js security advisory.

Next.js uses an internal header, x-middleware-subrequest, to count recursive middleware calls and stop an infinite loop. An external client was never meant to send it. When a request arrives carrying that header at a specific value, Next.js reads the request as an internal subrequest and runs no middleware at all.

Next.js 14.x and 15.x take this value:

Next.js 11.1.4 through 12.1.x take a middleware path instead:

The request needs no credentials and no special privileges, and it works from any network. A successful exploit can:

• Reach protected routes and admin panels
• Skip authentication and authorization checks
• Expose sensitive data and internal APIs
• Bypass rate limiting and other protective measures
• Poison the cache, which leads to denial of service

Prerequisites

• An Azion account. Refer to How to create an account on Azion.
• An application on Applications whose origin is your Next.js deployment.
• Access to Azion Console. To sign in, refer to How to access Azion Console.

Detect a vulnerable application

A deployment is vulnerable when its Next.js version falls inside one of these ranges:

The version is not always readable from outside the deployment. Four signals in an HTTP response point at a Next.js application that runs middleware:

• The x-powered-by: Next.js response header, which a deployment can turn off, so its absence proves nothing
• An x-middleware-rewrite or x-nextjs-cache response header
• A reference to /_next/static/ in a response body
• A response to the exploit header that differs from the response to a plain request

To probe one target, or a list of them, with the Nuclei template for CVE-2025-29927:

A positive match means the application runs Next.js with middleware headers. It does not name the version, so read the Next.js version in your deployment environment before you decide.

Create the mitigation rule

The Next.js advisory recommends blocking any external request that carries the x-middleware-subrequest header before it reaches the application. A rule with the Filter Request Header behavior removes that header from every incoming request, so Next.js never reads it and middleware runs as written. One rule covers every route of the application, needs no change to application code, and is created and removed independently of your release cycle.

To create the rule:

The rule appears in the Rules Engine tab of the application. It takes a few minutes to reach Azion’s distributed infrastructure, so a request sent right away can still carry the header through to the origin.

Validate the mitigation

Send the same request twice, once with the exploit header and once without it:

Both calls return the same response, because the header was removed before either request reached the origin. A protected route that the exploit header opened before the rule stays closed after it. To review the requests that reached the application, refer to Real-Time Events.

Upgrade Next.js to a patched version

The rule strips the header, and the vulnerable code stays in the deployment until you replace it. Upgrade to the patched release for your major version:

Once the patched release runs in production and the application behaves as expected, turn the rule off or delete it.

Next steps