On May 6, the Next.js and React teams shipped a coordinated security release that patched twelve disclosed vulnerabilities. One in React Server Components, eleven in Next.js. A follow up advisory landed the next day. The spread covered denial of service, server side request forgery, cross site scripting, middleware and proxy bypass, and cache poisoning. Basically the full bingo card.
If you ship a Next.js app, you needed to deploy a patched build this week. If you have not, you are running known exploitable software. This is the punch list.
The versions to upgrade to
Upgrade to 15.5.18 if you are on 15.x, or 16.2.6 if you are on 16.x. Anything below those on a public facing deployment is vulnerable. The version pin alone is not the fix. You also have to redeploy. We saw a handful of teams update package.json and forget to push.
Three of the twelve actually matter
Skim the rest, but these three are the ones to understand.
Middleware and proxy bypass. A malformed request could route past middleware checks entirely, including auth gates. If you rely on middleware to enforce login on a route, an attacker could hit the underlying handler without ever being authenticated. The fix is correct middleware routing in the patched version. If you cannot patch immediately, the mitigation is server side auth checks inside the handler too, which you should have anyway.
Cache poisoning. Specific request patterns could write attacker controlled content into the response cache that downstream legitimate requests would then receive. On a CDN, this means one attack request can poison cached responses for thousands of real users. Patch and purge your cache after deploying.
SSRF via image optimization. The image optimization endpoint could be coerced into fetching internal URLs. If your Next.js app runs in an environment with access to internal services (a VPC with a metadata endpoint at 169.254.169.254, for example), this is a way for an external attacker to query those services. The patch tightens the URL validation.
How to actually verify the fix
Running the new version is necessary but not sufficient. Three things to check.
First, confirm the deployed bundle. Run vercel inspect or curl -I against the deployed URL and read the x-vercel-cache headers. The deployment ID should be the post patch one. If your CI build was running during the patch window, you may have built against the old version and need to redeploy.
Second, purge the cache. The cache poisoning CVE means any cached response from the vulnerable period could still be malicious. vercel deploy --force bypasses ISR caches. CDN caches in front of Vercel may need a separate purge.
Third, audit middleware coverage. List every route that depends on middleware enforced auth and write a smoke test that hits each one with a malformed request pattern. Anything that returns 200 without auth, you have a bypass somewhere. Either in your middleware logic or in how the patch interacts with your specific setup.
The lesson, which is not new
Coordinated security releases happen. The teams that handled this well had three things in place before May 6. An automated dependency update bot already wired into CI. A deployment process that runs in under ten minutes. And a runbook for "security patch arrived, what do we do." The teams that struggled were the ones discovering on the day that their staging environment had not been updated in three months and the deployment pipeline took an afternoon to debug.
The next coordinated disclosure will happen. Probably this year. The preparation is not patching faster. It is having the muscle memory ready before you need it.