The RCE Behind “Not Affected”: CVE-2026-75604 Turns One Backslash Into a Windows Next.js Shell

Empirical Security named CVE-2026-75604 its October 2026 CVE of the Month today, and the pick is really two findings in one. The vulnerability is a CVSS 9.0 unauthenticated Windows path traversal in Next.js that leaks the Server Actions encryption key and, per the public Metasploit module, converts into a shell as the Node.js process. The meta-finding is how easily it disappears: Vercel's advisory scopes it in one line — "Linux and macOS are not affected by this issue" — and, Empirical argues, that line is exactly what gets the remaining vulnerable hosts bulk-closed by someone who knows the package version but not which server the build lands on.

The numbers behind the pick: Empirical's Foundation model scores it 0.918, 98th percentile; EPSS sits at 0.023 (82nd percentile); its sensor network observed in-the-wild exploitation activity on 18 September and again on 24 September 2026; a public Metasploit module exists; CISA KEV does not list it. This is a different bug from the ImageResponse SVG-injection RCE (CVE-2026-94545) we covered on 24 September — that one is fixed in the 16.3.6 line alongside this CVE's siblings, and the two stories share a lesson about scanner timing that is worth spelling out.

One encoded backslash, then the key, then the shell

Affected: Next.js from 13.4.0 up to the fixes in 15.5.24 and 16.3.3, self-hosted on Windows (typically behind IIS, per CyCognito's exposure tracking — a minority pattern inherited from older .NET estates). Route segments are not consistently escaped for backslashes before being used to build incremental-cache paths, so an encoded ..%5C in a route walks out of the cache root to server-reference-manifest.json, which holds the key Next.js uses to encrypt Server Action traffic between browser and server. With that key, an attacker forges Server Action values without authenticating; where the app has a Server Action capturing a form field in a closure, the Metasploit module turns forgery into command execution.

Note the conditions, because they are the difference between panic and triage. Empirical stresses the CVE text says "Pages Router or App Router" while Vercel's advisory and the exploit require both (App Router with Cache Components off), plus the default on-disk incremental cache, a dynamic ISR route, and a dynamic cached App Router route. There is no patched 13.x or 14.x release — those apps need a framework migration, not a patch window. And apps routing the incremental cache to Redis, S3, or another custom cacheHandler should not reach the vulnerable path at all, though Empirical cautions the advisory never states that carve-out, so confirm it per app rather than assuming it.

Two ways this one goes missing

The first is the scoping line. Since 8 September, dependency scanners flag the CVE in every repository pinning an affected Next.js version regardless of deployment OS. Faced with that list, bulk-closing as "Linux, not affected" feels reasonable — but the version string in the repo is not evidence of where the app runs. Worse, teams that pin NEXT_SERVER_ACTIONS_ENCRYPTION_KEY across fleets keep the finding open even for Linux instances: a key shared with any Windows deployment stays exposed until it is rotated, and a pinned key is baked in at build time, so it survives the upgrade. Empirical's rule is blunt: close as not-affected only on deployment evidence — manifest, container base image, host inventory — never on the version string.

The second is the pipeline lag. The ID was reserved 17 August and public in Vercel's advisory on 25 August, but the CVE record published 1 September — seven days against a 72-hour CNA target, a lag common enough to have a name (Reserved but Public). NVD and EPSS had nothing to attach to for a week; the GitHub Advisory Database that Dependabot, npm audit, and OSV read listed it only on 8 September. Late-August coverage, including The Hacker News on 27 August, reported no exploitation — and per Empirical, no outlet has revisited it since the exploitation signal arrived. If your intake opens tickets only on NVD entries, this is the case for changing it: open from vendor advisories the moment they cite a CVE ID, carry the GHSA ID alongside so findings merge, and recheck scope when the record publishes. We have made the same structural point about advisory snapshots going stale in yesterday's Obot write-up and the 72-CVE OpenClaw batch.

What to do

  • Scope on runtime evidence, then patch. Upgrade to 15.5.24 / 16.3.3 minimum (prefer current 15.5.26 / 16.3.6 — 16.3.6 also fixes the separate ImageResponse RCE GHSA-vcvr-r3jv-pc5j). For 13.x/14.x, file the migration exception now and treat the WAF rule below as the control until it ships.
  • Block the pattern while you patch. At the WAF or reverse proxy, block %5C, %255C in any case, or a literal backslash in the request path — checking the raw path and again after one decode round, scoped to the path, tested against legitimate traffic first.
  • Rotate the Server Actions key — after the fixed build is live. Delete .next/cache/.rscinfo (or the whole .next folder plus CI caches of it) before rebuilding, or the build reuses the old key for up to 14 days; if the key was pinned, generate a new one, set it in the build environment, rebuild once, and deploy that single build to every instance sharing the old key, Linux ones included. Rotating before the fix just exposes the new key the same way.
  • Hunt from 25 August onward. Search IIS and proxy logs for backslash patterns in route segments (especially under /_next/data/), Server Action POSTs (the Next-Action header or $ACTION_REF_/$ACTION_ID_ form fields — not the header alone), and node.exe spawning cmd.exe or powershell.exe. If traversal succeeded and the key was pinned, treat Server Action POSTs as suspect until rotation day; a stolen key replays from anywhere.

Caveats, carried over from Empirical's own write-up: the exploitation signal comes from a single sensor source, and with a public Metasploit module in circulation some activity may be testing rather than intrusion. EPSS ranks it high; KEV does not list it. We verified the analysis against Empirical's published timeline and references; we did not independently reproduce the traversal or the exploit.

Sources: