On 14 October 2026 Vercel shipped an out-of-band security release for Next.js: v16.4.1 (Active LTS) and v15.5.28 (Maintenance LTS) in the same batch.[1] Update (7 Nov 2026): 16.4.1 is no longer the floor - the November 2026 security release shipped v16.4.5 and v15.5.29 on 3 November with seven more advisories, so install those instead of the versions below.[2] This is not a routine patch. It fixes two Critical unauthenticated remote code execution (RCE) vulnerabilities and one High denial-of-service, and for anyone running Next.js on their own server this is the strongest upgrade trigger the framework has had in a while.[1]

If you self-host Next.js, the headline is simple: Vercel patches its own platform for you - you patch your own server. On Vercel, the fix lands in their infrastructure and you may not even notice. On a VPS you run, the vulnerable code is in the process you launched with PM2, and nothing updates it until you do. This guide is the self-hoster’s read of the release: what the three advisories actually affect, how to check whether your app is exposed, and the exact upgrade order that gets you patched without breaking a working deployment.

What the release fixes

The security update covers three vulnerabilities, all in upstream dependencies, all announced in the October 14 security update post.[1]

Critical - Unauthenticated RCE in use cache functions returning typed arrays (GHSA-673q-mjm6-r5xr). A vulnerability in applications using App Router with Cache Components can lead to unauthenticated remote code execution when a use cache function returns multiple typed arrays.[1] The related upstream advisory is GHSA-xqc2-xf4c-x3h3 (React).[1] There is no known workaround - Vercel’s own guidance is to upgrade immediately, “even if your application does not have similar functions."[1]

Critical - Unauthenticated RCE in the Image Optimization API when using SVG (CVE-2026-96889 / GHSA-2464-fhr4-w9xw). A memory-related vulnerability in an upstream library used for Image Optimization can lead to remote code execution when Next.js runs on glibc-based Linux.[1] The workaround, if you cannot upgrade right away, is to ensure the version of sharp used by Next.js is 0.35.5 or later; upgrading Next.js to the patched versions makes package managers provide the fixed sharp automatically.[1]

High - Denial of Service in App Router using Server Actions (GHSA-p3m5-59mp-jv5r). Crafted requests targeting an App Router app with at least one Server Action can cause excessive CPU usage, which blocks processing of further requests in the same process - a denial of service.[1] The related upstream advisory is GHSA-h3gv-c5rc-p453 (React).[1] Apps on Pages Router, or apps that don’t use Server Actions, are not vulnerable to this one.[1]

The self-hosting angle: Vercel patches itself, you patch yourself

The reason this release deserves a dedicated guide for self-hosters is the asymmetry in how the fix reaches you.

On Vercel, the patched Next.js version is rolled out across their infrastructure, and the Image Optimization and Server Actions paths run in an environment Vercel controls. Your app may be effectively protected the moment the platform updates, with no action on your part.

On your own VPS, none of that happens. The Next.js version is whatever your package.json and lockfile pin, the process is the one you started with node .next/standalone/server.js under PM2, and the sharp binary is the one your build pulled in. Nothing patches itself. The vulnerable code stays live until you run the upgrade, rebuild, and restart the process. That gap - between the release going public and your server actually running the fixed version - is the window an attacker has, and it’s entirely on you to close.

This is the same deployment path we covered end to end in the VPS deploy guide: build with output: 'standalone', copy the artifact, run it under PM2, proxy through nginx. A security patch doesn’t change any of that mechanics - it just makes the rebuild-and-restart step non-optional.

How to check if you’re vulnerable

Before you upgrade, it’s worth knowing which of the three paths your app actually touches. Here’s the practical checklist.

1. Do you use use cache with typed arrays? The RCE in GHSA-673q-mjm6-r5xr affects App Router apps using Cache Components where a use cache function returns multiple typed arrays.[1] If you adopted Cache Components (the recommended default since 16.4, covered in our Cache Components guide), grep your codebase for 'use cache' and check whether any cached function returns typed arrays such as Uint8Array, Int32Array, or Float64Array. But note Vercel’s warning: upgrade even if you don’t think you have such functions - the trigger surface is broader than a naive grep suggests.[1]

2. Do you use the Image Optimization API with SVG? The RCE in CVE-2026-96889 / GHSA-2464-fhr4-w9xw triggers when Next.js runs on glibc-based Linux and processes SVG through Image Optimization.[1] If your app serves user-uploaded or third-party SVG images through next/image, you’re on the exposed path. Check your sharp version: npm ls sharp should show 0.35.5 or later.[1] Most Linux VPS deployments are glibc-based, so this one is broadly relevant.

3. Do you use Server Actions? The DoS in GHSA-p3m5-59mp-jv5r affects App Router apps with at least one Server Action.[1] If you have any "use server" function, you’re in scope. If you’re on Pages Router or have no Server Actions, this specific advisory doesn’t apply to you.[1]

The honest answer for most self-hosted Next.js apps is: you’re probably in scope for at least one of these. App Router is the default, Server Actions are common, and Image Optimization with SVG is easy to hit without realizing it. The cost of upgrading is low; the cost of being wrong about your exposure is not.

The upgrade order for a self-hosted app

Here’s the sequence that gets you patched with minimal risk. It assumes the standard standalone build + PM2 setup from the deploy guide.

Step 1 - Pin and install the patched version. For the 16.x line, install next@16.4.1; for 15.x, next@15.5.28.[1]

npm install next@16.4.1   # for 16.x
# or
npm install next@15.5.28  # for 15.x

Step 2 - Verify sharp. Confirm the fixed version resolved: npm ls sharp should report 0.35.5 or later.[1] If your lockfile still pins an older sharp, the Next.js upgrade should pull the fixed one in, but verify it explicitly - this is the dependency that carries the Image Optimization RCE.

Step 3 - Rebuild the standalone artifact. Run your normal build (npm run build with output: 'standalone'), which regenerates .next/standalone. This is the step that actually bakes the patched code and the fixed sharp binary into what you deploy.

Step 4 - Deploy and restart the process. Copy the new artifact to the server, then restart PM2 so the running process picks up the patched build:

pm2 restart next-app

A restart is mandatory - a running process keeps the old code in memory until you restart it. If you run multiple PM2 instances, restart them all.

Step 5 - Smoke-test the app. Hit the routes that exercise the affected paths: a page that renders a use cache function, an image served through next/image (especially SVG), and a Server Action. Confirm they respond normally and the process stays healthy under load.

What not to do

  • Don’t wait for a “convenient” maintenance window. Two of these are unauthenticated RCEs with no workaround for the use cache one.[1] The exposure window is the time between the public release and your restart. Close it now.
  • Don’t rely on the sharp workaround alone. Pinning sharp >= 0.35.5 mitigates the Image Optimization RCE, but it does nothing for the use cache RCE, which has no workaround at all.[1] The workaround is a stopgap, not a substitute for upgrading.
  • Don’t skip the restart. Installing the package and rebuilding is not enough - the running PM2 process must be restarted to load the patched code.

The short version

Next.js v16.4.1 (and v15.5.28 for the 15.x line) shipped on 14 October 2026 as an out-of-band security release fixing two Critical unauthenticated RCEs - in use cache functions returning typed arrays (GHSA-673q-mjm6-r5xr, no workaround) and in the Image Optimization API with SVG on glibc Linux (CVE-2026-96889 / GHSA-2464-fhr4-w9xw, workaround: sharp >= 0.35.5) - plus a High DoS in App Router Server Actions (GHSA-p3m5-59mp-jv5r).[1] On Vercel the platform patches itself; on your own VPS you are the patch. Check whether you use use cache with typed arrays, Image Optimization with SVG, or Server Actions, then upgrade, verify sharp, rebuild the standalone artifact, restart PM2, and smoke-test. The upgrade mechanics are unchanged from the VPS deploy guide - only the urgency is new.

Sources

  1. Next.js - “Next.js Security Update for Upstream Vulnerabilities” (14 Oct 2026: v16.4.1 Active LTS + v15.5.28 Maintenance LTS; GHSA-673q-mjm6-r5xr Critical RCE in use cache typed arrays, no workaround; CVE-2026-96889 / GHSA-2464-fhr4-w9xw Critical RCE in Image Optimization with SVG on glibc Linux, workaround sharp >= 0.35.5; GHSA-p3m5-59mp-jv5r High DoS in App Router Server Actions; related upstream advisories GHSA-xqc2-xf4c-x3h3 and GHSA-h3gv-c5rc-p453; install commands next@16.4.1 / next@15.5.28). https://nextjs.org/blog/nextjs-security-update-october-14-2026 - checked 2026-10-15
  2. Next.js - “November 2026 Security Release” (2026-11-03: v16.4.5 Active LTS + v15.5.29 Maintenance LTS supersede 16.4.1 / 15.5.28; seven advisories). https://nextjs.org/blog/november-2026-security-release - checked 2026-11-07