Next.js shipped an out-of-band security patch on 22 September 2026 for a critical remote-code-execution bug in its image-generation feature, and it's already got a second patch (nine more vulnerabilities) scheduled for 30 September. If your site runs on your own VPS instead of Vercel's managed platform, nobody patches it for you. We checked our own client stack the day the advisory landed.
What is the Next.js critical vulnerability?#
It's CVE-2026-94545, a remote-code-execution flaw in Next.js's built-in next/og image generator, rated 9.5 out of 10 on the CVSS scale. Versions 16.2.0 through 16.3.5 are affected when running on Node.js. Next.js shipped the fix out of its normal release cycle on 22 September 2026.
The bug sits in ImageResponse, the function a lot of Next.js sites use server-side to generate OG images and social cards on the fly. Attacker-controlled input that lands in the SVG output wasn't escaped properly, so it could run as code instead of rendering as text, per Next.js's own advisory and the upstream Satori fix it references.
The Hacker News found no public exploit code as of 23 September, and that's not a reason to wait. A day later, Next.js posted advance notice of a second, scheduled release landing 30 September: one more critical bug, two high, five medium, one low.
Does this affect me if my site's on Vercel?#
Mostly not. If your site's on Vercel's managed platform, the fix is already in their build pipeline: check your deploy logs for the version bump and move on. This advisory is written for anyone self-hosting Next.js on their own server.
At WebEpex, we run client dashboards on our own VPS infrastructure with PM2 and Nginx in front of Next.js (DevAegis's dashboard is one of them, on Next.js 14), across our GCC, European, and North American client base, and that's exactly the setup this advisory targets. Nobody bumps the version in your package.json automatically. If whoever built your site never got past next build and a cron restart, you're carrying whatever version you shipped with until someone runs npm install next@16.3.6 and redeploys, which is exactly what running your own infrastructure costs you that a managed platform doesn't.
The other thing worth checking, regardless of hosting: do you actually use ImageResponse? A lot of sites generate one OG image per blog post or product page for social sharing. If you don't touch that API at all, your exposure is lower even on an older version, though we'd still patch, because the 30 September release covers bugs nobody's described publicly yet.
The honest trade-off#
Patching now costs almost nothing on the 16.3 line: it's a dependency bump, not a breaking change, and Next.js says explicitly it's safe to apply straight away. The real cost is awareness: most teams don't have anyone whose job is reading Next.js's security blog, so 22 September passes and nobody notices until a scanner flags it three months later.
The genuine trade-off shows up around the 30 September release. Next.js is withholding those nine advisories until the patch ships (standard practice, and the right call), but it means patching twice inside eight days. My honest read: apply 16.3.6 now for the confirmed critical bug, don't wait for the bundle, then patch again on the 30th once the follow-up lands.
One real unknown: whether the 16.2.x line gets its own backport at all. As of this writing it doesn't: the only path is forward to 16.3.6, which may be a bigger jump than a one-line bump for anyone who stayed on 16.2 deliberately.
How we're handling it#
We checked every Next.js site we run against this the day the advisory landed. DevAegis's dashboard and a couple of others on our VPS stack got the next@16.3.6 bump and a PM2 restart that same afternoon, ahead of anything else on that week's list. None were feeding attacker-controlled input directly into ImageResponse, but "probably fine" isn't a patching strategy, so we upgraded anyway.
We're holding the 30 September release to the same treatment: read the advisories the moment they're public, patch same-day for anything high or critical, queue the rest. That's the same rhythm we use for n8n's security releases: a scheduled release isn't a smaller release, it just means Vercel had time to write better documentation first.
For clients on managed hosting, we're not touching anything, and that's the point of paying for managed. For clients we host ourselves, patch cadence is quietly part of what they're paying for, even if it never shows up as a line item on a proposal.
What I'd tell a client asking about this#
Three things, in order:
- Check whether your site's on Vercel or self-hosted: that answer decides whether you do anything at all.
- If you're self-hosted, run
npm list nexttoday. Below 16.3.6 or 15.5.26, upgrade before anything else on your list; it's a low-risk bump, not a rebuild. - Grep your codebase for
next/og. Two minutes, and it tells you exactly how urgent this is for your setup.
Worth pairing the check with a look at how your Next.js site's speed affects conversion while you're already in the codebase. Then put 30 September on your calendar and do it again.
If you want a second pair of eyes on your Next.js version before then, send me what you're running and I'll tell you straight in a couple of minutes, no pitch attached. cal.com/webepex/growth-review