A Critical Next.js Fix Is Still Coming. Your Website Won't Patch Itself.

Next.js published version 16.3.8 at 12:07 p.m. Eastern on September 30, with fixes for seven security bugs. By 5:19 p.m. the next day, we'd moved all 130 Next.js websites we run to the fixed versions, and each one was rebuilt and tested on its own before its update was saved. We pushed them live after midnight: 128 were serving the fix between 12:33 and 1:40 a.m. on Friday, October 2, and one more by 6:17 a.m. The last one is built and goes live with a launch it's being held for. None of our clients got a bill for it.

We're telling you that because of a line in Next.js's own release note: two more fixes, one of them rated critical, are still waiting on upstream coordination. A website built on a modern framework is software, and software runs on a patch clock. Every framework ships bugs. What decides whether one hurts you is how long your live site keeps running the old version after the fix is out. We think the next held-back fix will split Next.js sites into two groups within a week of its release: the ones somebody maintains, and the ones still running whatever version they launched on.

TL;DR

• Next.js fixed a critical remote code execution bug in its share-image tool on September 22, for versions 16.2.0 through 16.3.5, then seven more security bugs on September 30 in versions 16.3.8 and 15.5.27.
• Two more fixes, one critical and one high severity, are coming in a later release, and Next.js 15 reaches the end of its two-year support window on October 21.
• You can check your site's version in about a minute (steps below). If it's under 16.3.8, or under 15.5.27 on the 15 line, ask whoever runs your site when the update will be live.

What did Next.js fix in September?

Key fact: Next.js shipped eight security fixes in eight days. The first, on September 22, closed a critical remote code execution bug in next/og, the tool many sites use to draw the preview image that appears when a page is shared.

The September 22 advisory covers versions 16.2.0 through 16.3.5 and only the Node.js version of ImageResponse. Under specific conditions, improper escaping in the image code could lead to remote code execution through other upstream dependencies. Sites using the Edge version weren't affected, and neither was Next.js 15. The fix is version 16.3.6.

The September 30 release fixed seven more, in 16.3.8 and 15.5.27:

• One high severity: server-side request forgery in image optimization, which only affects sites that allow remote images through images.remotePatterns.
• Five medium: two ways to poison the cache of statically generated pages, share-image routes that can be made to render pages a site deliberately left out, and two caching bugs that can show content to the wrong audience, including unpublished drafts.
• One low: a leak in the development server, which production sites don't run.

Next.js had announced the release a week early with nine fixes planned. Two, one critical and one high, were held back pending upstream coordination and "will be addressed in a later Next.js release."

What did we do?

We run 130 Next.js websites, from client sites and microsite networks to our own tools. On Thursday, October 1, we moved every one of them to 16.3.8. One older internal app took the matching 15.5.27 fix first and moved up to 16.3.8 that night.

The 36 sites that draw their share images with next/og on the Node.js runtime, the exact code the critical bug lived in, went first. Every site was rebuilt from a clean install and started up, and we confirmed its pages rendered on the server and, where it has one, its share-image route returned a real image before its update was saved. A second pass then rechecked all 130 from scratch.

Keeping a site's framework patched is part of running the site, so it isn't something we bill for. A developer who bills each security release as a change order gives you a reason to put the next one off, and the next one is already announced.

How do you check your site's version?

It takes about a minute in a desktop browser.

1. Open your website in Chrome, Edge or Firefox.
2. Right-click anywhere on the page, choose Inspect, then click the Console tab.
3. Type next.version and press Enter.
4. Compare the number it shows:
   • 16.3.8 or higher, or 15.5.27 or higher on the 15 line: you have the September 30 fixes.
   • 16.2.0 through 16.3.5: you're missing the September 30 fixes and you're inside the critical September 22 range, which matters most if your site draws share images on the server.
   • Any other 16 or 15 version below those: you're missing the September 30 fixes.
   • 14 or lower: Next.js no longer supports that version, and these fixes didn't ship for it.
   • An error: your site probably isn't built on Next.js, and its platform has its own update schedule.

What should you ask whoever runs your site?

• What version of Next.js is my site on today, and when did the latest fix go live?
• Who watches for security releases, and how long does a fix take to reach my live site?
• Is patching included in what I pay, or billed separately?
• What's the plan for the two fixes Next.js says are still coming?
• If my site is on version 15, what happens before October 21?

Where is this headed?

Here's what we think happens next, and we'd bet on all three.

• Next.js will ship the two held-back fixes before the end of 2026, and the week they land will be the riskiest stretch of the year for unmaintained sites. A published fix shows attackers where the bug was. The sites that update that week close the gap. The rest become the easy targets.
• Plenty of Next.js 15 sites will keep running past October 21 without a plan. Next.js says it'll patch versions outside its policy "in rare circumstances." We wouldn't build a business on rare circumstances.
• By the end of 2027, "Who patches the framework, and how fast?" will be a standard question when businesses hire a web developer, as routine as asking who owns the domain.

In September we wrote about hackers exploiting WordPress plugins. Different platform, same lesson: the risk lives in the gap between a published fix and your live site. Patching is part of our maintenance and support, and if you're not sure what your site runs, send us the address and we'll tell you.