Next.js Middleware Authorization Audit: Upgrade the Turbopack Fix

If a Next.js App Router application relies on middleware or proxy checks to protect content, treat the May 2026 security release as an upgrade-and-audit task. The release addressed an authorization bypass through transport-specific route variants; a follow-up was required because the first fix did not apply to middleware.ts when Turbopack was used.

Know which applications need the audit

The affected pattern is an App Router app where middleware.js or proxy.js is part of the authorization boundary. The original advisory describes segment-prefetch and .rsc transport variants reaching a page without the expected matcher protection in affected versions. That is not a reason to remove middleware; it is a reason not to make it the only place that decides whether protected data may be returned. Read the original advisory before classifying your routes.

Upgrade past the follow-up, not merely the first patch

The first advisory was followed by a Turbopack-specific correction: the initial fix did not apply to middleware.ts with Turbopack. The follow-up lists 15.5.18 and 16.2.6 as patched versions. Vercel’s coordinated release also lists those versions and says patching is the complete mitigation. Do not stop at 15.5.16 or 16.2.5 if your project uses this authorization pattern. See the follow-up advisory. See the release guidance.

Audit the authorization boundary before and after deployment

Start by listing routes whose content, data loaders, or Server Functions require a signed-in user or a role. For each route, identify the check that protects the data itself. A redirect in middleware is useful early filtering, but the page, route handler, or data-access layer should still reject an unauthenticated caller before returning protected data.

npm ls next
rg "middleware|proxy|auth|session|role" app src pages

Make the verification a negative test

After upgrading, test an unauthenticated request against each protected route in the same deployment configuration you run in production. The expected result is a redirect, 401, or 403 according to the route’s contract, and never protected data. Include routes covered by dynamic segments and any route that uses React Server Component transport. Keep the test focused on the authorization outcome rather than copying exploit-shaped URLs from an advisory.

Deploy the smallest safe change

Pin the upgraded Next.js version, regenerate the lockfile with the package manager used in CI, and run the production build plus the negative authorization checks. Review middleware matchers, but prioritize authorization at the data-returning boundary. That leaves the application protected if a future routing or transport variant falls outside an early matcher.

This is a time-sensitive post: the exact patched version is accurate for the May 2026 release. For future upgrades, use the current Next.js advisory and release notes, then rerun the same route-level authorization tests.