Next.js and the corrupt middleware: the authorizing artifact

Timeline is interesting

Timeline:

02/27/2025: vulnerability reported to the maintainers (specifying that only versions between 12.0.0 and 12.0.7 were vulnerable, which was our understanding at the time)

03/01/2025: second email sent explaining that all versions were ultimately vulnerable, including the latest stable releases

03/05/2025: initial response received from the Vercel team explaining that versions 12.x were no longer supported/maintained (probably hadn’t read the second email/security advisory template indicating that all were vulnerable)

03/05/2025: another email sent so that the team could quickly take a look at the second email/security advisory template

03/11/2025: another email sent to find out whether or not the new information had been taken into account

03/17/2025: email received from the Vercel team confirming that the information had been taken into account

03/18/2025: email received from the Vercel team: the report had been accepted, and the patch was implemented. Version 15.2.3 was released a few hours later, containing the fix (+backports)

03/21/2025: publication of the security advisory

The lag & missing key details

How serious this vulnerability is depends entirely on how the site that's being attacked uses middleware. The auth thing is just the most obvious example of how an attacker can do bad things if they have the ability to selectively disable middleware by passing names as a colon separated list in an HTTP header.

(I've built sites that would have been affected by this in the past, had I used Next and middleware for auth. I've worked on plenty of systems where there are only a small set of users each with the same level of permissions - gating private documentation for example.)

The vulnerability can be understood through this code snippet:

  const subreq = params.request.headers['x-middleware-subrequest'];
  const subrequests = typeof subreq === 'string' ? subreq.split(':') : [];
  // ...
  for (const middleware of this.middleware || []) {
    // ...
    if (subrequests.includes(middlewareInfo.name)) {
      result = {
        response: NextResponse.next(),
        waitUntil: Promise.resolve(),
      };
      continue;
    }
  }

Pass an x-middleware-subrequest HTTP header with a colon-separated list of middleware names to skip.

https://github.com/vercel/next.js/blob/v12.0.7/packages/next...

Probably depends on the complexity of the permissions in the application. I'd also expect something more along the lines you described for more complex applications. The middleware would do authentication, but then just attach that information to the request. Later parts would then use the attached information to make decisions about permissions/authorization.

In more complex cases this would be outside middleware, so it should fail as no authentication/authorization information is attached to the request if you skip that middleware.

But putting the security checks into middleware could easily make sense for more rigid or simple cases. In C# for example I can add attributes to the methods that handle each endpoint. So if you need a basic admin/no-admin check you could add a [RequireAdmin] attribute on the relevant endpoints and use a middleware to check that.

I would agree that checking the URL in middleware to make decision about permissions would be a bad idea, it moves this important check to a mostly invisible place.

This probably also allows different attacks, e.g. skipping middleware that does other security-relevant checks (maybe anti-CSRF mechanisms could be vulnerable here).