Next.js's First Scheduled Security Release Shipped: 9 Advisories, What to Patch

Three weeks ago, Vercel announced that Next.js’s first scheduled security release would ship July 20, 2026, covering 4 high and 5 medium severity issues, with no other detail until the patch was actually out. We wrote about the program itself at the time, because the notice was the news. Now the release has shipped, a day later than planned, and the specifics are public. Here’s what was actually in it.

What shipped

The release landed July 21, 2026, patching Next.js 16.2 and 15.5 across 9 advisories: 4 high severity, 5 moderate. That matches the severity ceiling Vercel pre-announced almost exactly, which is itself worth noting: the program’s whole premise was that a severity level, published in advance without technical detail, would be enough for teams to plan an upgrade window. In this first real test, the number held.

The four high-severity issues

Two of the four are server-side request forgery (SSRF) flaws, which is the category most likely to matter if your deployment does anything unusual with routing or hosting:

• GHSA-p9j2-gv94-2wf4: SSRF in rewrites via an attacker-controlled destination hostname. If your next.config rewrites route to a hostname built from request input, this is the one to check first.
• GHSA-89xv-2m56-2m9x: SSRF in Server Actions running on custom servers. Teams that dropped the default Vercel/Node runtime for a custom server setup are the ones most exposed here.
• GHSA-6gpp-xcg3-4w24: a Middleware/Proxy bypass affecting App Router applications using Turbopack with a single configured locale. This is a narrower condition (Turbopack plus single-locale routing specifically) but a full bypass of Middleware-enforced logic, including auth checks, is a high-impact outcome regardless of how narrow the trigger.
• GHSA-m99w-x7hq-7vfj: denial-of-service in App Router applications using Server Actions.

The five moderate-severity issues

• GHSA-4c39-4ccg-62r3: unbounded Server Action payload size in the Edge runtime, which without a cap opens the door to resource-exhaustion abuse.
• GHSA-68g3-v927-f742 and GHSA-4633-3j49-mh5q: both are cache confusion issues affecting response bodies for requests that carry a body, with the second one specifically triggered by invalid UTF-8 byte sequences in that body. Cache confusion bugs are the kind that can leak one user’s response to another if your caching layer sits in front of the affected routes.
• GHSA-q8wf-6r8g-63ch: denial-of-service in the Image Optimization API through crafted SVGs.
• GHSA-955p-x3mx-jcvp: unauthenticated disclosure of internal Server Function endpoints, which is an information-disclosure issue worth checking even if it didn’t make the high-severity cut.

As of this writing, Vercel has published GHSA identifiers for all nine but hadn’t yet cross-filed formal CVE numbers, consistent with how the program said it would run: advisories and fixes first, CVE paperwork to follow.

The pattern worth paying attention to

Look at where the high-severity issues cluster: Server Actions appear in three of the four, and Middleware/Proxy handling in one more. That’s not new. May 2026’s 13-advisory emergency release also concentrated heavily in middleware bypass and cache-layer issues. Server Actions and Middleware are two of the areas where Next.js has pushed the most new capability over the past year, and they’re also, unsurprisingly, where most of 2026’s security patching has landed. If your application relies on either heavily for auth, routing, or data mutation, that’s the part of your codebase that deserves an extra pass in review, not just a version bump.

Severity	Count	Advisories
High	4	GHSA-p9j2-gv94-2wf4, GHSA-89xv-2m56-2m9x, GHSA-6gpp-xcg3-4w24, GHSA-m99w-x7hq-7vfj
Moderate	5	GHSA-4c39-4ccg-62r3, GHSA-68g3-v927-f742, GHSA-4633-3j49-mh5q, GHSA-q8wf-6r8g-63ch, GHSA-955p-x3mx-jcvp

What to do now

1. Upgrade to the patched 16.2.x or 15.5.x release if you haven’t already, prioritizing the SSRF and Middleware bypass fixes if you run custom servers, use rewrites with dynamic hostnames, or route by locale on Turbopack.
2. Check whether your caching layer sits in front of the affected routes, since two of the moderate issues are response-body cache confusion, the kind of bug that turns into cross-user data leakage under the wrong CDN configuration.
3. Re-audit anything built on Server Actions, given how often that surface has appeared across both this release and May’s. That includes checking payload size limits on the Edge runtime specifically, which is what GHSA-4c39-4ccg-62r3 was about.
4. Watch the GitHub advisories page directly rather than relying solely on blog recaps, since CVE numbers and any expanded technical detail tend to get filled in over the following days.

The bigger takeaway from this first cycle is that the program did what it said it would: a known date, a known severity ceiling, and no surprises in the actual count when the release landed. If your upgrade process still treats every framework patch as an emergency, this is the model worth copying regardless of which framework you’re on: publish the ceiling early, keep the details locked until the fix ships, and let teams plan around a calendar date instead of a scanner alert.