Skip to content
Insights

NQ Solution

Next.js Security Patches: Sept 2026 Guide

Next.js fixed a critical next/og RCE on 22 Sept 2026 and seven more issues on 30 Sept. Is your site affected, what to upgrade to, and what can break.

Next.js had three security releases in five weeks. On 22 September 2026 an out-of-band update fixed a critical remote code execution issue in the Node.js ImageResponse (next/og), and on 30 September a scheduled release fixed seven more issues. If your site runs Next.js 16, it should now be on 16.3.8 or later; a Next.js 15 site should be on 15.5.27 or later. Two further fixes (one critical, one high) were postponed for upstream dependencies, so check the Next.js blog for the latest patched version before you upgrade.

This guide is written for two readers. The first half is for site owners who need to know whether their site is affected and what to ask their developer. The second half is for the developer doing the upgrade.

What were the September 2026 Next.js vulnerabilities?

Here is the short version, in date order. All of it comes from the official Next.js blog and the GitHub security advisories for the vercel/next.js repository.

DateReleaseWhat it fixedWho is affected
25 August 202616.3.3 and 15.5.24Two critical remote code execution issues: AVIF image optimisation (through sharp and libheif) and Windows-hosted serversSites that optimise attacker-supplied AVIF images; Windows servers running both routers without Cache Components
22 September 202616.3.6 (15.5.26 is hardening only)Critical remote code execution in the Node.js ImageResponse from next/og (GHSA-vcvr-r3jv-pc5j)Next.js 16.2.0 up to 16.3.5 using the Node.js runtime for OG images; the Edge implementation and Next.js 15 are not affected
29 September 202616.3.7A bug fix only, no security fixes—
30 September 202616.3.8 and 15.5.27Seven issues: one high, five medium, one lowDepends on features used (see below)
PendingNot yet releasedOne critical and one high issue, waiting on upstream fixesNot yet disclosed

A quotable summary: Next.js 16.2.0 up to 16.3.5 were affected by a critical remote code execution issue in the Node.js `ImageResponse` (`next/og`), fixed in 16.3.6 on 22 September 2026 (GHSA-vcvr-r3jv-pc5j).

The seven issues fixed on 30 September are narrower. Most need a specific feature to be switched on:

  • Server-side request forgery in Image Optimization (high). Only applies if you have configured images.remotePatterns. An allow-listed remote host could be abused to reach private IP ranges from your server.
  • Two cache-poisoning issues (medium). One affects self-hosted sites using the Pages Router with SSG or ISR pages (Vercel deployments are not affected). The other affects sites that combine a root-level catch-all page with SSG or ISR routes.
  • Metadata image routes ignoring `dynamicParams` (medium). Only App Router apps built with webpack; Turbopack builds are not affected.
  • Two Cache Components issues (medium). One can serve cached content keyed to the wrong root parameter; the other can leak Draft Mode (preview) content into regular pages.
  • Development server endpoint (low). Only affects next dev, not production.

The Next.js team publishes a notice a few days before scheduled releases, so watching the blog gives you time to plan.

Is my website affected? (version check in 2 minutes)

As a site owner, you need three answers. You can ask your developer for all three in one email.

  1. Which Next.js version does the live site run? The developer can read it from package.json and the lockfile, or run npm ls next. On many Next.js sites you can also open the browser console on the live page and type next.version. That shows the version the page was built with, not whether the server has been updated since, so treat it as a first check.
  2. Does the site generate images with `next/og`? These are usually the social preview images that appear when a page is shared. If the site uses them on the Node.js runtime and the version is between 16.2.0 and 16.3.5, it was exposed to the 22 September issue.
  3. When was the site last deployed with dependency updates? A site built in July and not touched since is missing every fix released after that, so each advisory has to be checked against it.
Your versionWhat it meansWhat to do
16.3.8 or laterIncludes the fixes released so farWatch for the postponed critical fix
16.2.0 to 16.3.7Missing at least the 30 September fixes; below 16.3.6 also missing the critical next/og fixUpgrade to the latest 16.3.x
16.0.x to 16.1.xMissing the August and September fixesUpgrade to the latest 16.3.x and test
15.5.27 or laterPatched within the 15.x linePlan the move to 16 when convenient
Older 15.x or 14.xLikely missing several fixesAsk for an upgrade plan; check the advisories for your exact version

Hosting matters less than people think. A managed host can block some attacks at its edge, and some advisories state that Vercel deployments are not affected. But the vulnerable code is in your app's dependencies, and only a rebuild with a patched version removes it.

What breaks when you upgrade to 16.3.8?

For most apps, moving within 16.3.x is a small change: bump next, eslint-config-next and any @next/* packages, rebuild and test. Teams who have patched many apps report a few recurring problems. One r/nextjs post in early October 2026, from a team upgrading dozens of apps, listed these:

  • `sharp` moves from 0.34 to 0.35. In standalone output, check that the libvips shared library from @img/sharp-libvips-* is actually in your build. On one app it was not traced, and every OG image returned a 500 error with ERR_DLOPEN_FAILED. Adding the files through outputFileTracingIncludes fixed it.
  • Stricter build-time type checks. Test files that import a path ending in .ts failed with TS5097 after the upgrade. Setting allowImportingTsExtensions (with noEmit already on) resolved it.
  • Image routes need their own test. Because two of the recent issues sit in image generation and optimisation, a passing home page tells you little. Open a page's OG image URL and an optimised image URL on the staging build.

Our checklist for a framework patch, in order:

  1. Read the advisories and note which ones apply to the features this site uses
  2. Update only the framework packages first; leave unrelated upgrades for later
  3. Build the way production builds (same Node.js version, same output mode)
  4. Start the production build locally or on staging, not just next dev
  5. Check pages, forms, logins, OG images and optimised images against the live site
  6. Deploy, then confirm the live version number
  7. Note the date and version in the maintenance log

How long should a security patch take your developer?

There is no honest single number. A patch release within the same minor version is often quick to apply. The time goes on everything around it: reading which advisories apply, building the way production builds, checking the pages that matter, deploying and confirming. A site that has not been updated for a year may need several intermediate upgrades first, and each can break something.

What you can reasonably expect from a developer:

  • A plain answer to "are we affected?" within the version and feature terms above.
  • A short description of the work: which version you are moving to, what they will test, and when the site will be deployed.
  • A record afterwards: the old and new version, the date, and anything that needed fixing.

If you are billed for the work, ask for that breakdown rather than arguing over the total. Time spent on staging checks is not padding. That is the part that stops a security fix from breaking your contact form.

Should you turn on Next.js 16.4's agentUpgrade reminders?

Next.js 16.4, released on 6 October 2026, adds two features aimed at keeping apps patched. The next upgrade --agent command checks your installed version, picks a target release, and prepares migration guides, codemods and verification steps for a coding agent to follow. The new experimental.agentUpgrade setting prompts you during next dev or next build when a relevant upgrade is available. Its default policy, 'security', only reminds you about upgrades that fix known vulnerabilities affecting your installed version.

For a team that works on the codebase every week, the reminder costs nothing and catches missed advisories. It does not replace a maintenance process for two reasons:

  • It only fires when someone runs a dev server or a build. A site nobody touches for three months gets no reminder.
  • It is a nudge, not a deployment. Someone still has to apply the change, test it and ship it.

If you use a coding agent for the upgrade itself, treat the result like any other change: review the diff and check the running site. We cover how in how to review AI-written code.

What should a website maintenance plan cover for framework patches?

A maintenance plan is where "someone should check this" becomes a named task. For a Next.js site, ask for these points to be written down:

ItemWhat to agree
MonitoringWho watches the Next.js blog and GitHub advisories for your version
ScopeFramework and dependency patches, not only content edits
TestingWhich pages and features are checked before each deploy
Hosting accessWho can deploy, and where the build settings live
RecordsA log of versions and dates you can see
Out-of-band issuesHow critical advisories are handled between scheduled updates

Without a plan, patches tend to happen only when something visibly breaks.

How we handle this on client projects

We build most sites with Next.js, and we build with security checks as part of the work: permissions, input validation, dependency patching and checks for what is exposed to the public internet. For releases like September's, dependency patching starts with reading each advisory against the features a site actually uses, such as next/og images, images.remotePatterns, self-hosting and Draft Mode, before upgrading.

We develop and review code every day with Claude Code, an AI coding agent, and a person reviews every change before it ships. Dependency upgrades get the same treatment: the agent can prepare the change, and a person checks it before it ships.

Hosting and maintenance are a separate contract from the build, so the scope of patching is written down rather than assumed. We do not sell standalone security audits or penetration tests, and no developer can promise that a site will never have a vulnerability. What we can do is keep the framework current and tell you plainly what changed. If your site was built by someone else and you are not sure of its state, our vibe-coded app security checklist covers the other common gaps.

Frequently asked questions

How do I check which Next.js version my site uses?

Ask your developer to check package.json and the lockfile, or run npm ls next. On many live Next.js sites you can type next.version in the browser console, which shows the version the page was built with.

Are sites on Vercel automatically protected?

Not entirely. Some advisories, such as the 30 September SSG and ISR cache-poisoning issue for self-hosted Pages Router apps, state that Vercel deployments are not affected. Others depend on your code and dependencies, which only a rebuild with a patched Next.js version fixes.

Is Next.js 15 affected by the next/og RCE?

No. The 22 September advisory affects Next.js 16.2.0 up to 16.3.5. Version 15.5.26 includes related hardening, but the remote code execution issue does not affect 15.x. Next.js 15 sites should still move to 15.5.27 for the 30 September fixes.

Why did my OG images break after upgrading?

The usual cause reported so far is the sharp upgrade to 0.35. In standalone builds, the libvips library it needs may not be included, so image routes return 500 errors. Check the build output and add the missing files with outputFileTracingIncludes.

What does website maintenance cost per month?

It depends on what is covered: monitoring advisories, patching, testing, hosting and content changes. We agree hosting and maintenance in a separate contract from the build, with the scope written down, so you know which of these tasks is included.

Sources

All checked October 2026.

Not sure if your site was patched?

Send us the URL and what you know about how the site was built, and we will tell you which Next.js version it appears to run and what an upgrade involves. Use the project request form or email dwkim@nqsolution.kr. Our web development service page explains how we build and maintain sites.

Planning a similar project?

Send us your goals, scope and timeline. The two of us who would build it reply directly.

Prefer email? Write to dwkim@nqsolution.kr — the founder replies directly.