Next.js 16.4.1 and 15.5.28 fix critical use cache and SVG RCEs

Next.js 16.4.1 and Next.js 15.5.28 fix two critical remote-code-execution vulnerabilities and a high-severity denial-of-service flaw. One issue affects the App Router and functions marked use cache; the other originates in SVG image processing on glibc-based Linux systems. The first issue has no vendor-provided workaround, making an upgrade essential.

The security update published on 14 October 2026 matters to organisations running shops, customer portals and SaaS platforms on Next.js. Not every application has the same exposure, but failing to find a matching cache function in business code is not a reason to defer the fix. For critical advisory GHSA-673q-mjm6-r5xr, the official guidance is to upgrade even when the application does not appear to return the described data types.

The priority action: establish the Next.js version in every deployment, upgrade to 16.4.1 or 15.5.28, rebuild artifacts from scratch and prove that production is running the new package. Editing package.json alone does not close the risk.

What does Next.js 16.4.1 fix?

The update covers three important scenarios. Two may allow unauthenticated remote code execution, while the third can exhaust CPU resources.

GHSA-673q-mjm6-r5xr: critical use cache RCE

The first vulnerability affects Next.js 16 deployments using the App Router and Cache Components. Where a use cache function returns multiple typed arrays, a crafted request may lead to remote code execution on the server.

The advisory covers versions 16.0.0 through 16.4.0 and identifies 16.4.1 as fixed. It carries a 9.5 CVSS v4 score. The vendor provides no effective workaround and, importantly, recommends upgrading every deployment in the affected range even when the team cannot find a similar function in its own application.

CVE-2026-96889: critical SVG optimisation RCE

The second issue is tracked as CVE-2026-96889 and GHSA-2464-fhr4-w9xw. It stems from a memory-safety defect in a component used for image optimisation. Processing SVG on glibc-based Linux servers may result in code execution without authentication.

Affected Next.js releases include 10.0.0 through 15.5.27 and 16.0.1 through 16.4.0. Fixed releases are 15.5.28 and 16.4.1. Using sharp 0.35.5 or later is an alternative control for this specific issue, but upgrading Next.js provides a fixed dependency and is easier to evidence.

GHSA-p3m5-59mp-jv5r: denial of service through Server Actions

The third flaw is rated high severity. It affects App Router applications with at least one Server Action. Crafted requests can consume excessive CPU and reduce service availability. Pages Router-only applications and applications without Server Actions are outside this particular scenario.

Which organisations and applications are exposed?

Urgent action is required where teams:

• run Next.js 16.0.0–16.4.0 with the App Router and Cache Components;
• run Next.js 10.0.0–15.5.27 or 16.0.1–16.4.0 with server-side SVG optimisation;
• use the App Router and Server Actions in an affected release;
• build a shared base image or template for multiple customer applications;
• retain internet-accessible preview, staging or dormant deployments.

The version must be checked in the lockfile and built artifact, not only in a dependency declaration. A range such as ^16.0.0 may resolve differently according to install date, cache state and package manager. A monorepo may also contain several applications on different releases.

How to upgrade Next.js safely

1. Inventory every deployment

Search repositories, lockfiles, SBOMs, container images and the hosting platform. Include production, staging, preview deployments, old domains and starter templates. Assign an owner and exact version to each instance.

2. Upgrade the appropriate LTS line

Move Next.js 16 to at least 16.4.1 and the maintained 15 line to at least 15.5.28. Refresh the lockfile in a controlled change, run tests and review transitive dependency updates. Do not copy an old node_modules directory into the new image.

3. Rebuild and redeploy the application

A new commit does not prove that production has changed. Rebuild images and artifacts without reusing an affected cache, publish them and verify the deployment identifier. Remove or restrict old instances that may still receive traffic.

4. Test business functions

Exercise caching, page generation, Server Actions, image uploads and optimisation, sign-in, payments and integrations. Monitor errors, latency and CPU use. A security update still needs normal quality controls.

5. Retain closure evidence

Record the affected and target versions, deployment list, test outcome, publication time and approving owner. In a secure CI/CD process, this evidence should be generated automatically and a critical dependency finding should block promotion of an old artifact.

Will a WAF protect Next.js from these RCEs?

A WAF may suppress some suspicious traffic and buy time, but it is not a confirmed replacement for these updates. New input variants can evade signature rules, and traffic to server functions may resemble legitimate requests.

If a full rollout has to wait, restrict public access to test deployments, disable unnecessary optimisation of untrusted SVG files, apply request limits and alert on CPU spikes. For the SVG issue, sharp 0.35.5 or later is an official mitigation, but it does not fix the separate use cache vulnerability.

Source facts and Breachroad conclusions

The Next.js team confirms affected versions and configurations, two RCE paths, the DoS scenario, fixed releases and the absence of a workaround for the critical use cache issue. GitHub advisories confirm version ranges and a 9.5 CVSS v4 score for both RCEs.

Inventorying preview deployments, performing clean rebuilds, retaining deployment evidence and testing business paths are Breachroad recommendations. Organisations can make this operating model repeatable through cybersecurity training for development teams, while high-value applications can be examined through an IT security audit.

Next.js 16.4.1 critical RCE FAQ

Which Next.js version should we install?

For the active 16 line, install at least 16.4.1. For the maintained 15 line, install at least 15.5.28. Continue tracking subsequent vendor security releases.

Is the Pages Router affected by the use cache RCE?

The GHSA-673q-mjm6-r5xr scenario affects the App Router with Cache Components. A Pages Router application may still require an update for other vulnerable components, including SVG optimisation.

Is disabling SVG enough?

It may reduce exposure to CVE-2026-96889, but it does not fix the use cache RCE or the Server Actions DoS. Moving to a fixed Next.js release is the most complete response.

How can we confirm the production version?

Read the version from the lockfile and SBOM associated with the exact artifact or image, then map that artifact to the production deployment ID. The declaration in package.json does not prove which build is serving traffic.

Primary sources: Next.js — Security Update, 14 October 2026, GitHub Advisory — GHSA-673q-mjm6-r5xr, GitHub Advisory — GHSA-2464-fhr4-w9xw.