Critical Next.js update without taking production down

On 22 September 2026, Next.js published a security update outside its usual release schedule. The update fixes a critical issue that, under certain conditions, can allow unauthorised code to run on the server.

Updating the package is not the only important step. You also need to check which version the app is actually running, whether it uses the affected image feature, and whether the new build works with authentication, payments and other key flows.

What has changed

According to the Next.js security advisory from 22 September 2026, Next.js versions from 16.2.0 up to, but not including, 16.3.6 are affected. The fixed version for the active LTS branch is 16.3.6.

Next.js has also published 15.5.26 for apps that remain on the 15.x maintenance branch. That branch is not reported to be vulnerable to this particular remote code execution issue, but the update includes related security hardening.

The issue is in the Node.js version of ImageResponse from next/og. This feature is often used to create dynamic images, such as previews shown when a page is shared on social media. It uses the Satori dependency, which converts interface code into SVG.

The vulnerability becomes relevant when values that a visitor can influence are passed into SVG content, attributes or styles. Incorrect handling of these values, together with other dependencies, can lead to code running on the server. The Edge version of ImageResponse is not affected by the same issue.

The absence of an obvious image page in your app's navigation does not mean the feature is not present. It may be in a route for Open Graph images, in a template from Lovable or in code added by a package.

Check whether the app is affected

Start in the project's root directory and check the installed version. If you use npm, run:

npm ls next

Also check package.json and the project's lockfile. The lockfile, such as package-lock.json or pnpm-lock.yaml, shows which version the build actually installs. Changing the version in package.json is not enough if the updated lockfile is not committed to Git and included in the deployment.

Next, search the code for the following expressions:

grep -R "ImageResponse\|next/og" app pages src

The search may report errors if the project does not contain some of the directories, but it will still show results from directories that exist. You can also use search in GitHub, VS Code or Lovable.

Review the results and check whether data from URL parameters, forms, the database or user profiles is passed into SVG elements, attributes or styles. Names, headings, profile text and image URLs should be treated as user-controlled if they can be changed outside trusted code.

Use this checklist:

• Confirm which Next.js version is installed from the lockfile
• Search for ImageResponse and next/og
• Check whether affected routes use Node.js or Edge
• Identify values that visitors or users can influence
• Check whether the same repository contains multiple Next.js apps
• Check that the production build uses the same lockfile you are reviewing

Even if you do not find ImageResponse, an affected 16.x version should be updated. The absence of a code match is not a good reason to leave a known security vulnerability open, particularly when generated code or dependencies may make its use less visible.

Upgrade the correct version branch

If the app already uses 16.x, update to 16.3.6:

npm install next@16.3.6

If the app uses 15.x, install the hardened version:

npm install next@15.5.26

If the project uses pnpm, Yarn or Bun, use the equivalent command and let the same package manager update the lockfile. Do not mix package managers or edit the lockfile manually.

If the app is on an older major version, do not install 16.3.6 without checking first. A major version upgrade may require code changes. The security advisory does not specify a separate fixed version for older, unsupported branches, so treat this as planned upgrade work and verify the framework's current support status.

After installation, run the project's usual build locally. Also check that Git shows changes to both the package file and the lockfile. If only package.json has changed, the production environment may still install something other than what you intended.

Test before deployment

Create a preview deployment in Vercel or an equivalent environment. Use the same environment variables and external services normally used for testing, but avoid real payments and unintended emails.

Check the flows that could disrupt the business if they stop working:

• Registration, sign-in and sign-out
• Password resets and one-time sign-in links
• Redirects after OAuth sign-in
• Protected pages and middleware
• Retrieving and updating data in Supabase
• Stripe Checkout in test mode
• Payment return paths for successful and cancelled purchases
• Stripe webhooks and subscription status updates
• Dynamic Open Graph images and other ImageResponse routes
• Key forms, emails and background jobs

Also review the build logs. Warnings about dependencies, a changed runtime or failed routes may indicate that the preview environment does not match production.

Then deploy during a period when someone can monitor logs and error reporting. A previous deployment may be useful if a feature fails, but rolling back also restores the older, vulnerable version. The aim should therefore be to fix forward and make the updated version stable.

If an immediate upgrade is not possible, temporarily prevent attacker-controlled values from reaching SVG content, attributes or styles in the Node.js version of ImageResponse. Disabling the affected image route is safer than trying to filter individual characters without fully understanding how the SVG is interpreted. This is a temporary mitigation, not a replacement for the update.

Once the app has been updated and the critical flows are working, the next step may be to check how the product is prepared for paying customers.

Source: Next.js blog