Next.js Critical RCE Bugs: Patch Your Self-Hosted App Now

Find the release your server actually runs

Your dependency update finishes successfully, but production still serves an older build. This happens when you patch a checkout while systemd runs a separate release directory, or when a container keeps using an existing image. Start by finding the running application's deployment path, then patch the source that produces that release.

This procedure assumes Ubuntu 24.04 LTS on a single VPS. Commands involving an application require your existing deployment account and checkout, so they are marked as environment-dependent. The example application lives at /srv/next-app, and its systemd unit is next-app.service; substitute your actual deployment values before using those blocks.

systemctl show next-app.service --property=WorkingDirectory --property=ExecStart --property=MainPID
cd /srv/next-app
pwd
node -p "require.resolve('next/package.json')"
node -p "require('next/package.json').version"
npm ls next sharp --all

For Docker Compose, inspect the running service's image and inspect dependencies inside that container. Updating packages on the host does not update an image already running. Follow your established Docker Compose production deployment procedure to build and replace the application container.

Do not print the service environment or copy secret files into a support conversation. You need the executable path and dependency versions, not database credentials. We let Claude Code gather this evidence with read-only commands before giving it permission to change the deployment.

Match your application to the affected features

Next.js announced the out-of-band update on 8 October 2026 for release on 14 October 2026. It covered two Critical and one High vulnerabilities in upstream dependencies, with two issues postponed from the September security release. Use the conditions below to understand exposure, but do not delay the upgrade while trying to prove a vulnerable feature is unreachable.

The Cache Components advisory describes Critical unauthenticated remote code execution, related to upstream React advisory GHSA-xqc2-xf4c-x3h3. It carries a CVSS v4 base score of 9.5 and had no CVE ID assigned. Next.js states that there is no known workaround and advises upgrading immediately even without matching functions.

getconf GNU_LIBC_VERSION

The Server Actions advisory describes crafted requests causing excessive CPU usage that blocks the process. This is a denial of service, so a process can remain running while requests stop completing. Do not send exploit-shaped requests to production to determine whether you qualify.

Install the security release for your supported line

On 14 October 2026, Next.js released v16.4.1 for Active LTS and v15.5.28 for Maintenance LTS. Choose the release matching your supported application line. The official release announcement provides the install commands below.

Make the change in the source checkout used by your deployment pipeline. Check for existing edits before installing, then review both the manifest and lockfile afterward. These examples use npm; if the repository uses another package manager, preserve that package manager and its lockfile.

cd /srv/next-app
git status --short
npm install [email protected]
git diff -- package.json package-lock.json
npm ls next sharp --all

Use the following install command instead when your application belongs on Maintenance LTS. These are alternatives, so do not run both install commands in sequence. For an older application outside these supported lines, consult the official advisory and plan the required migration rather than assuming a dependency override patches the framework.

cd /srv/next-app
npm install [email protected]
git diff -- package.json package-lock.json
npm ls next sharp --all

Keep unrelated dependency upgrades out of this patch. A smaller diff makes compatibility failures easier to diagnose and gives you a clear artifact to deploy. Avoid adding a broad dependency repair command simply because it appears in terminal advice.

Verify the sharp dependency that Next.js resolves

CVE-2026-96889 is Critical unauthenticated remote code execution in the Image Optimization API when SVG files are used on glibc-based Linux. The cause is a memory-related flaw in an upstream library. The image optimization advisory assigns a CVSS v4 base score of 9.5.

The documented workaround is to ensure that the sharp version used by Next.js is 0.35.5 or later. Upgrading Next.js makes package managers provide a fixed sharp automatically. Check what Next.js actually resolves because a top-level dependency listing can hide a different nested copy.

cd /srv/next-app
node <<'NODE'
const { createRequire } = require('node:module');
const nextRequire = createRequire(require.resolve('next/package.json'));
const sharpPath = nextRequire.resolve('sharp/package.json');
console.log('Resolved sharp package:', sharpPath);
console.log('Resolved sharp version:', nextRequire(sharpPath).version);
NODE
npm explain sharp

If an urgent compatibility problem forces you to use the sharp workaround, follow the advisory and your package manager's dependency controls, then repeat this resolution check. Do not assume installing sharp globally changes the application's dependency tree. The workaround addresses the image issue; it does not replace the framework upgrade for the Cache Components issue.

Build a replacement production artifact

A changed lockfile does not patch a process already serving requests. Build from the reviewed dependency change using your normal production build environment. Keep the build separate from the directory the live process uses, because installing packages into a running release can leave mixed dependencies.

The following commands belong in an isolated build checkout with the updated manifest and lockfile already present. Run the application's established checks as well, especially those covering image rendering and server-side behavior. A successful build establishes that the artifact can be assembled; it does not prove every application path works.

cd /srv/next-app-build
npm ci
npm run build
node -p "require('next/package.json').version"
npm ls next sharp --all

For standalone output, assemble the complete release using the repository's deployment script. For containers, build a replacement image from the updated lockfile. The VPS deployment ladder explains how to move from editing a live directory toward repeatable releases.

Give an operations agent the dependency diff and build logs, then require a clear deployment target before it restarts anything. We keep this boundary explicit in our production agent guardrails. A patch request should not silently become permission to alter unrelated services.

Deploy and verify the replacement process

Publish the completed artifact through your existing deployment procedure, then replace the running process. The example restart below assumes that procedure has already installed the patched release and pointed the service at it. Restarting before that step simply launches the old application again.

sudo systemctl restart next-app.service
systemctl is-active next-app.service
systemctl show next-app.service --property=WorkingDirectory --property=ExecStart --property=MainPID --property=ExecMainStartTimestamp
sudo journalctl -u next-app.service --since today --no-pager

Inspect dependencies inside the deployed artifact as well as the build checkout. If your standalone layout differs from the example, use the actual directory containing its server and dependencies. A version read from disk is useful evidence only when you connect it to the release the replacement process launched.

cd /srv/next-app/current
node -p "require('next/package.json').version"
node <<'NODE'
const { createRequire } = require('node:module');
const nextRequire = createRequire(require.resolve('next/package.json'));
console.log(nextRequire('sharp/package.json').version);
NODE

Open the public application and exercise a normal optimized image, then submit a harmless Server Action if the application has one. Check the resulting logs for application errors. If you must roll back a broken deployment, remember that an older vulnerable artifact restores the exposure; restrict public access while preparing a corrected patched build.

Record the patched release and check every deployment

Record the deployed commit or image identifier alongside the runtime dependency versions and your normal smoke-check result. Then check other public deployments of the same repository, including previews that remain reachable. A patched main site does not update a forgotten service using its own lockfile or image.

• Identify each reachable deployment and the account responsible for it.
• Match its running artifact to the patched dependency change.
• Confirm its replacement process starts and ordinary application requests work.
• Keep a follow-up task for any temporary sharp workaround.

Do not turn this patch into an emergency hosting migration. If managing runtime updates repeatedly falls through the cracks, use the Next.js hosting comparison during your next infrastructure review. For now, finish verifying the server you already operate.

Your next concrete task is to make dependency verification part of release completion. Follow the GitHub Actions to VPS deployment procedure to carry the reviewed lockfile into a repeatable artifact, then record which artifact the service launched. Assign an owner to the next advisory review before closing this change.