CVE‑2025‑29927 – Critical Next.js Authorization Bypass – Immediate Action Required

What breaks and who should care

If you run a Next.js application that relies on middleware for authorisation, a vulnerability discovered in early 2025 could let unauthorised users reach protected routes. Any service exposing a Next.js front‑end to the internet – e‑commerce sites, internal dashboards, SaaS platforms – needs to treat this as a high‑priority issue.

This flaw sits alongside the rest of CISA’s catalogue on our actively-exploited vulnerability tracker.

What the vulnerability is

The flaw is an authorisation bypass that occurs when a request passes through Next.js middleware. The framework checks the x‑middleware‑subrequest header to decide whether a request is an internal sub‑request or an external one. An attacker can craft a request that tricks the middleware into treating the call as trusted, skipping the checks that would normally block access.

Because the bypass happens inside the framework, it does not require any special payload or code execution. Simply sending a request with the header in the right format can be enough to obtain data or actions that should be restricted.

The exact details of the bypass – the internal logic that decides when the check is skipped – have not been fully disclosed by the vendor. What we do know is that the problem only appears in versions that fall within the affected ranges listed in the table below.

How bad is it?

The Common Vulnerability Scoring System gives this issue a score of 9.1, which is classified as critical. That rating reflects three factors: the vulnerability is easy to exploit, it requires no authentication, and it grants full access to whatever the middleware protects.

In practice, an attacker could read confidential user data, modify records, or perform actions that should be limited to administrators. The impact is therefore severe, especially for applications that handle personal data, financial information or internal tooling.

There is no public evidence that the vulnerability is being actively weaponised in the wild, but the severity rating means you should assume it can be exploited if left unpatched.

How to tell if you’re affected

The first step is to identify which version of Next.js your project is using. The easiest way is to look at the package.json file or ask the package manager.

• Run npm list next or yarn list --pattern next in your project directory. The output will show the exact version installed.
• If you use a lock file, open package-lock.json or yarn.lock and search for the string next@. The version follows the @ symbol.
• For Docker‑based deployments, inspect the image layers or run docker run --rm your-image npm list next.

Compare the version you find with the ranges in the table below. If your version falls inside any of the affected ranges, you are vulnerable.

What to do if you are vulnerable

The recommended fix is to upgrade to the patched release for your branch of Next.js. The vendor has released a safe version that removes the faulty header handling. Upgrade the package, rebuild your application and redeploy.

Typical upgrade commands look like this:

• npm install next@latest – pulls the newest version that includes the fix.
• yarn add next@latest – same for Yarn users.
• If you pin to a specific major version, replace @latest with the appropriate branch identifier, e.g. next@13 or next@14. The exact version number is omitted here; the table below shows which branch contains the fix.

After upgrading, run your test suite, especially any integration tests that hit protected routes. Verify that the middleware still behaves as expected and that no regressions have been introduced.

Mitigation if you cannot patch immediately

In some environments a full upgrade may be delayed – for example, when a large monorepo is tied to a specific Next.js version for compatibility reasons. In those cases you can apply a temporary mitigation that blocks the problematic header from reaching the application.

Configure your edge or reverse proxy to drop any incoming request that contains the x‑middleware‑subrequest header. The exact configuration depends on the web server you use.

• Nginx: add a rule in the server block
  if ($http_x_middleware_subrequest) { return 403; }
• Apache: use RequestHeader unset X-Middleware-Subrequest or return a 403 when the header is present.
• Cloudflare Workers: inspect the request headers and return a Response with status 403 if the header exists.

This mitigation stops the bypass vector, but it also prevents legitimate internal sub‑requests that rely on the header. Test your application after applying the rule to ensure that internal routing still works. If you notice broken functionality, you may need to adjust the rule to allow trusted internal traffic only.

Verification after remediation

Once you have either upgraded or applied the header block, confirm that the vulnerability is no longer exploitable.

• Run a scan with your favourite SAST/DAST tool and confirm that CVE‑2025‑29927 is no longer reported.
• Manually send a request that includes x‑middleware‑subrequest and verify that the server returns a 403 or behaves as if the header were absent.
• Check your logs for any 403 responses generated by the mitigation; they indicate that the rule is active.

If the scanner still flags the issue, double‑check that the running instance matches the version you built. In containerised environments, make sure the image you deployed is the one you rebuilt after the upgrade.

What if a patch is impossible

In rare cases an organisation cannot move to a newer Next.js release – perhaps due to legacy dependencies or a strict change‑control process. If the upgrade path is blocked for an extended period, you should treat the header block as a permanent defence.

Document the mitigation in your security policies, and monitor the upstream project for any future back‑ported fixes. When the time comes to upgrade, plan a migration that includes testing for breaking changes, as the patch may introduce behavioural adjustments beyond the security fix.

Summary checklist

• Identify the Next.js version in use via npm list next or equivalent.
• Cross‑reference with the table below – if your version is in an affected range, you are at risk.
• Upgrade to the patched release for your branch as soon as possible.
• If you cannot upgrade, configure your edge/reverse proxy to reject any request containing x‑middleware‑subrequest.
• Run a post‑remediation scan and manually test the header block.
• Document the change and schedule a future upgrade if you are using the mitigation long‑term.

Version table

The table below lists the affected and fixed versions for each major release line. Use it to confirm whether your current version needs an upgrade.

Affected versions

Straight from the NVD record for CVE-2025-29927. If your build is inside one of these ranges, treat it as vulnerable.

Product	Affected range	Fixed in
next.js	11.1.4 up to 12.3.5	12.3.5
next.js	13.0.0 up to 13.5.9	13.5.9
next.js	14.0.0 up to 14.2.25	14.2.25
next.js	15.0.0 up to 15.2.3	15.2.3