On this page (7 sections)
A critical vulnerability in Next.js can lead to unauthenticated remote code execution in applications that use the App Router with Cache Components. According to the GitHub security advisory, the risky pattern is a use cache function that returns multiple typed arrays. The fix is in version 16.4.1.
If you run a Next.js 16 site or ship Next.js apps for clients, check your version today. The advisory says there is no known workaround, so upgrading is the only documented remedy.
What happened
The advisory was published on October 14, 2026 in the vercel/next.js repository. The GitHub Advisory Database reviewed it and updated its entry on October 22, 2026. It describes unauthenticated remote code execution in applications using the App Router with Cache Components, when a use cache function returns multiple typed arrays.
At the time of writing, this is the only source in our research, and it is the advisory itself. We have not seen independent analysis, a CVE record or reports of exploitation, so treat anything beyond the advisory text as unconfirmed.
Technical details
The advisory states the impact in short terms: applications using the App Router with Cache Components can be exposed to remote code execution, and the application needs a use cache function that returns multiple typed arrays. Typed arrays are JavaScript's binary data containers, such as Uint8Array or Float32Array. The advisory does not explain the root cause, and we will not guess at it.
The CVSS v4 metrics listed in the advisory explain the high score:
- Attack vector: network, so it can be reached remotely
- Attack complexity: low, with attack requirements marked as present
- Privileges required: none, and no user interaction
- Impact on the vulnerable system: high for confidentiality, integrity and availability
- Impact on subsequent systems: high for confidentiality and integrity, none for availability
In plain terms, the scoring assumes an attacker would not need an account or a victim's click, and that a successful attack could affect the confidentiality, integrity and availability of the vulnerable application. The advisory also says to upgrade immediately even if your application does not have similar functions, so do not rely on a quick code review to rule yourself out.
Who is affected
The advisory describes exposure as applications that meet all of these conditions:
- They use the
nextnpm package at version 16.0.0 through 16.4.0 - They use the App Router with Cache Components
- At least one
use cachefunction returns multiple typed arrays
Because the advisory recommends upgrading regardless of whether you have such functions, treat every Next.js 16.0.0 to 16.4.0 deployment as needing the update. Agencies should check every client project and any preview or staging deployments that are reachable from the internet.
How to check your exposure
Start with the installed version. This read-only command, run from the project root, shows which version of next your dependency tree resolves to. Look for a version between 16.0.0 and 16.4.0 inclusive.
npm ls nextIf you use another package manager, the equivalent read-only queries are below. They print the resolved next version in the same way.
pnpm why next
yarn why nextThen search your source for the feature in question. This grep lists lines that contain the use cache directive so you can see where cached functions live. Review each one for functions that return typed arrays.
grep -rn "use cache" --include=*.ts --include=*.tsx --include=*.js --include=*.jsx app src 2>/dev/nullWhat to do now
The documented fix is to move to Next.js 16.4.1, per the advisory, which also points to the v16.4.1 release. This command, run in the project root, updates the dependency to the patched version.
npm install next@16.4.10 of 7 done
Because the advisory lists no workaround, do not count on a firewall rule or configuration toggle as a substitute. A web application firewall can add a layer of defense, but we have no research showing that any specific rule covers this flaw. See what a WAF is for what that layer can and cannot do.
Detection and monitoring
The research does not describe indicators of compromise or any observed attacks, so we cannot give specific signatures. Practical steps that apply to any server-side code execution bug are:
- Check application and reverse proxy logs for spikes of unusual requests to cached routes
- Look for unexpected child processes, new files or outbound connections from the Node.js process
- Compare your deployed build against your repository to spot unexpected changes
- Watch for changes to your site's headers, certificates and DNS, which sometimes follow a server takeover
If you suspect a compromise, follow our guide on what to do when a website is hacked. For ongoing visibility into outside-facing changes, Webforta Monitor tracks uptime, certificate, DNS and header changes. That helps with spotting side effects, but it does not replace patching.
What we do not know yet
- No CVE identifier appears in the research, only the GHSA identifier
- No public reports of exploitation are mentioned
- The root cause and the exact request pattern are not described in the advisory text we have
- Only one source covers this so far, so details may change as maintainers or researchers publish more
We will update this article if the advisory is revised or exploitation is reported. For more security news and analysis, see the Webforta blog.
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.