Next.js makes it convenient to build React applications with server-side rendering, server components, caching, and image optimization. However, these server-side features also mean that security issues can affect more than the browser.
On October 14, 2026, the Next.js team published an out-of-band security update addressing two critical remote code execution vulnerabilities and a high-severity denial-of-service vulnerability.
The patched releases are Next.js 15.5.28 and 16.4.1. The vulnerabilities affect different parts of the framework, including Cache Components, the Image Optimization API, and Server Actions. (Official Next.js security announcement)
If you maintain a production Next.js application, this is worth checking even if you have already updated your dependencies recently.
Let's look at what is affected, how to check your application, and what you should do before deploying a fix.
What makes these vulnerabilities important?
Next.js performs several operations on the server rather than leaving everything to the browser.
For example, an application may:
Execute server-side code to prepare a page.
Cache the results of server functions.
Process uploaded or externally supplied images.
Execute Server Actions that update application data.
Use native libraries for image processing.
If one of these components has a security flaw, an attacker may be able to reach it through an HTTP request.
The October security update addresses three distinct problems. They should not be treated as one vulnerability because their affected features and mitigations differ.
1. Critical RCE in use cache functions
The first issue is documented in GitHub security advisory GHSA-673q-mjm6-r5xr.
It affects Next.js applications using the App Router with Cache Components when a use cache function returns multiple typed arrays.
Typed arrays are JavaScript objects used to work with binary data. Examples include Uint8Array and Int16Array.
A simplified example of a cached function returning typed arrays looks like this:
async function getBinaryData() {
"use cache";
const first = new Uint8Array([10, 20, 30]);
const second = new Uint8Array([40, 50, 60]);
return {
first,
second,
};
}This example illustrates the data type involved. It is not a demonstration that this function, by itself, triggers the vulnerability. Exploitation depends on the specific vulnerable framework behavior and application configuration.
The security issue can allow unauthenticated remote code execution in affected applications.
The relevant distinction is that authentication is not necessarily required before an attacker can reach the vulnerable framework behavior.
Which versions are affected?
The advisory identifies Next.js versions 16.0.0 through 16.4.0 as affected.
The patched release is:
Next.js 16.4.1The framework team states that there is no known workaround for affected applications. It recommends upgrading immediately, even when the application does not appear to contain a use cache function returning multiple typed arrays.
That recommendation matters because searching your source code for one particular pattern is not an adequate replacement for installing the fix.
2. Critical RCE in the Image Optimization API
The second issue is tracked as CVE-2026-96889 and documented in GitHub advisory GHSA-2464-fhr4-w9xw.
This vulnerability concerns the Image Optimization API when processing SVG files.
Next.js can optimize images on the server. Its image-processing pipeline relies on native libraries, including sharp. The issue originates in an upstream library used by image optimization and can lead to remote code execution when Next.js runs on glibc-based Linux systems.
The affected versions listed in the advisory include:
Next.js 10.0.0 through 15.5.27.
Next.js 16.0.0 through 16.4.0.
The published fixed versions are Next.js 15.5.28 and 16.4.1. Use the release appropriate for your application's supported branch.
Why should developers pay attention to SVG processing?
SVG is an XML-based image format. Unlike ordinary pixel-based images, SVG files contain structured document data that must be parsed and interpreted.
Image-processing libraries must handle that input safely.
A vulnerability in an image-processing dependency can therefore affect a server even when the application does not contain an obvious custom image-processing function.
For example, a project might use the standard Next.js image component:
import Image from "next/image";
export default function ProductImage() {
return (
<Image
src="/product.svg"
alt="Product illustration"
width={500}
height={300}
/>
);
}This is an ordinary usage example, not an exploit. The security concern is the affected server-side image-processing path and its handling of particular SVG input.
Is updating sharp enough?
The advisory describes a temporary workaround: ensure that the version of sharp used by Next.js is 0.35.5 or later.
However, this workaround specifically addresses the SVG image-processing vulnerability. It does not resolve the separate use cache remote code execution issue.
The preferred solution is to upgrade Next.js to a fixed version so the dependency resolution includes the appropriate fix.
If you need to use the sharp workaround while preparing the upgrade, verify the actual resolved version in your lockfile and deployment rather than assuming that a package declaration guarantees which version runs in production.
3. High-severity denial of service in Server Actions
The third issue affects Next.js applications using the App Router with at least one Server Action.
According to the official Next.js announcement, specially crafted requests can trigger excessive CPU usage, blocking the affected process from handling further requests.
This is a denial-of-service issue rather than the same remote code execution problem described above.
An application might have a Server Action such as:
"use server";
export async function updateProfile(formData) {
const name = formData.get("name");
// Validate the input and save the profile.
}This snippet illustrates the general feature, not the vulnerability.
The reported issue concerns how vulnerable framework code processes particular crafted requests. Ordinary validation inside your own action is not a substitute for updating the framework.
The advisory specifies that applications using the Pages Router, or applications that do not use Server Actions, are not affected by this particular denial-of-service vulnerability. However, those applications may still be affected by the separate image-optimization issue depending on their versions and configuration.
How to check your current Next.js version
Start with your local project.
Run:
npm ls next react react-dom sharpThis displays the dependency versions resolved for these packages. It is particularly useful for checking which Next.js and image-processing dependencies are installed.
You can also check the framework version directly:
npx next --versionThen inspect the project manifest:
cat package.jsonCheck the version in package-lock.json, pnpm-lock.yaml, or yarn.lock, depending on which package manager the project uses.
Remember that the version in package.json may be a version range. The resolved version in the lockfile is important because that is what the deployment should install.
Also check the deployed application, especially when it runs inside Docker or another managed deployment environment. The version installed on your laptop does not prove that the production server is running the same version.
How to fix the vulnerabilities
Choose a patched Next.js release appropriate for your project.
For an application maintained on the Next.js 15.5 branch:
npm install next@15.5.28For an application using Next.js 16.4:
npm install next@16.4.1These are examples for the specified branches. If your project uses an older release, another supported branch, or different React dependencies, review the framework's upgrade guidance and compatibility requirements before changing versions.
If your application uses pnpm or Yarn, use the equivalent command for your package manager.
After the update, inspect the resolved packages:
npm ls next react react-dom sharpReview the resulting changes to package.json and your lockfile. Commit those changes to version control so that your local, staging, and production environments can install the same dependencies.
Test the application before deploying
A dependency update is not complete simply because the installation command succeeds.
Run the project's available checks:
npm ci
npm run build
npm testThe test command assumes the project defines a test script. If it does not, use the checks appropriate to your application.
Test the following areas in particular:
Image optimization: Verify that images load correctly through the Next.js image pipeline, including any SVG handling that your application supports.
App Router pages: Check routes that depend on server components, caching, and the use cache directive.
Server Actions: Test form submissions and other features that execute actions on the server.
Authentication and authorization: Confirm that login, session handling, and protected operations behave as expected.
Deployment: Verify that the production image or runtime contains the patched packages.
If your application uses Docker, rebuild and redeploy the image as part of the update. Installing a patched version on the host does not update a separate container that still contains the old dependencies.
What about a Web Application Firewall?
A WAF can help filter certain suspicious requests, but it should not be treated as the primary fix for these vulnerabilities.
The flaws concern framework or dependency behavior. A generic firewall rule cannot be assumed to block every request that might reach the vulnerable path.
Similarly, adding extra input validation to a Server Action does not repair a flaw in the framework's request processing.
Update the affected dependencies first. Use the firewall, request limits, monitoring, and application-level checks as additional layers of protection.
A practical security checklist for Next.js projects
Whenever a critical framework advisory is published, I recommend checking the following:
Identify the actual version used in production.
Review the official advisory to understand the affected feature and version range.
Upgrade to a patched release compatible with the project.
Review the lockfile and resolved transitive dependencies.
Rebuild the application or container from the updated dependencies.
Test image optimization, caching, Server Actions, and other relevant features.
Verify that the production deployment runs the updated build.
Review logs if the application was exposed while vulnerable and investigate suspicious activity where appropriate.
Do not assume that a successful update proves the application was never exploited. Patching addresses the vulnerability; investigating historical activity is a separate task.
Conclusion
The October 2026 Next.js security update addresses problems in caching, image optimization, and Server Actions. Each issue has a different technical cause, but the immediate lesson is the same: keeping the framework and its dependencies up to date is part of maintaining a secure production application.
If you use Next.js 15 or 16, check your actual dependency versions and follow the official upgrade guidance. If you maintain an older application, identify the appropriate supported fixed release instead of blindly copying an installation command.
The most important lesson is that server-side framework features need to be treated as part of your application's security boundary. Caching, image processing, and Server Actions are useful features, but they depend on framework and library code that must be maintained.