The Cache Returns Shells: Next.js’s October Out-of-Band Fixes Two Unauthenticated RCEs and a Server Actions DoS

On 14 October 2026 Vercel published an out-of-band Next.js Security Update for Upstream Vulnerabilities (Sebastian Silbermann, Josh Story, Karim Rahal) carrying three advisories: two unauthenticated remote code executions, both rated Critical Severity, and a Server Actions denial of service rated High. Patched releases are v16.4.1 (Active LTS) and v15.5.28 (Maintenance LTS). Two of the three fixes were postponed from the September security release because of upstream dependency delays — the framework knew it was exposed and waited on someone else’s patch. Both RCEs are reachable without credentials, and for one of them the vendor’s instruction is unambiguous: upgrade immediately even if your application does not have similar functions.

This is our fourth Next.js security briefing in five months, after CVE-2026-44578’s WebSocket SSRF in AI-generated apps, CVE-2026-94545’s ImageResponse RCE and CVE-2026-75604’s cache-traversal RCE. The framework that scaffolds most AI-generated web applications keeps producing unauthenticated network-reachable execution flaws in its caching and image pipelines — and this release puts one in each.

GHSA-673q-mjm6-r5xr: the use cache function that returns execution

The first Critical is GHSA-673q-mjm6-r5xr (Next.js), with related upstream advisory GHSA-xqc2-xf4c-x3h3 (React). In applications using App Router with Cache Components, a use cache function returning multiple typed arrays can lead to unauthenticated remote code execution. The vendor states there is no known workaround and instructs operators to upgrade immediately even when their application contains no such functions — which tells you the defect is framework-level deserialization or boundary handling, not an application bug you can grep for and feel safe about.

For agent-built front ends this is the sharpest of the three. Cache Components and use cache are exactly the patterns AI coding tools emit when asked to make a Next.js app fast: cached data-fetching functions returning binary payloads are idiomatic generated code. The attack surface is not a misconfiguration; it is the default output of the toolchain, served on an unauthenticated route.

CVE-2026-96889 / GHSA-2464-fhr4-w9xw: SVG in, shell out, via librsvg

The second Critical is CVE-2026-96889 / GHSA-2464-fhr4-w9xw: a memory flaw in an upstream library used for Image Optimization that yields remote code execution when Next.js runs on glibc-based Linux — which is to say, on effectively every containerized deployment — with SVG as the trigger format. The vendor workaround is to ensure the sharp used by Next.js is 0.35.5 or later, noting that upgrading Next.js makes package managers provide the fixed sharp automatically.

The upstream flaw is real and we read it first-hand: the NVD record for CVE-2026-96889, published 23 September 2026 from Red Hat (status Awaiting Analysis at time of reading), describes a librsvg use-after-free (CWE-416) when processing SVG documents containing nested XML inclusions (XIncludes) with duplicate entity declarations — the library frees an XML entity the parser still holds. Its CVSS 3.1 vector is 7.8 AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. Note the mismatch: upstream scores a local library bug at 7.8, while the same bytes delivered to an unauthenticated image-optimization endpoint become framework RCE. Anyone triaging on the NVD number alone sees a moderate local flaw; the framework context is where the severity lives.

We verified the sharp upgrade path directly against the npm registry, and there is a genuine operational trap in it. Version 16.4.1 declares sharp ^0.35.5 in optionalDependencies, so a fresh install heals itself — but 15.5.28 declares ^0.34.3 || ^0.35.5, meaning a 15.x deployment with sharp already installed at 0.34.x can upgrade Next.js and silently keep the vulnerable native module. If you run the Maintenance LTS, npm ls sharp after upgrading is not optional. Registry timestamps confirm the release sequence: 15.5.28 at 17:36 UTC and 16.4.1 at 17:43 UTC on 14 October, with a further 16.4.2 following on 15 October at 20:57 UTC. And context from our own archive: this is the second SVG/image-pipeline RCE in Next.js in about two weeks, after September’s CVE-2026-94545 ImageResponse flaw — the image pipeline is the repeat offender.

GHSA-p3m5-59mp-jv5r: Server Actions as a CPU-exhaustion button

The High is GHSA-p3m5-59mp-jv5r (Next.js), upstream GHSA-h3gv-c5rc-p453 (React): crafted requests against App Router applications with at least one Server Action cause excessive CPU usage that blocks processing of further requests in the same process. Pages Router applications and apps without Server Actions are not vulnerable. The same-process detail is what makes this more than a nuisance for agent deployments, which overwhelmingly run single-process Next.js behind minimal hosting: CPU exhaustion there is not degradation, it is a full stop of the agent’s web surface, including any webhook or callback endpoints the agent loop depends on.

What the databases knew at publication

Two measurement notes, both made at time of writing. First, all three GHSA identifiers returned 404 from the GitHub advisory database (API and web) roughly a day after the vendor blog published — the now-familiar lag in which scanners ingesting GHSA or OSV have nothing to match, exactly the window pattern we documented in the better-auth batch. Second, trade-press coverage characterizes both RCEs at CVSS 4.0 9.5, but the vendor blog itself carries no numeric scores — only Critical/High labels — so treat those numbers as unattributed until the GHSA records land. The rule stands: patch on the vendor’s word, score later.

Remediation

Upgrade next to 16.4.1+ or 15.5.28+ (16.4.2 is current on the Active line). On the 15.x line, explicitly verify sharp ≥ 0.35.5 with npm ls sharp — the upgraded framework will otherwise happily run against a stale vulnerable native module. There is no workaround for the use cache RCE: the vendor’s “even if you don’t have similar functions” means inventory cannot substitute for patching. For the DoS, confirm whether you run App Router with Server Actions; Pages Router deployments are not affected. And given two image-pipeline RCEs in a fortnight, consider what your image-optimization endpoint accepts from unauthenticated callers as a standing question, not a one-time patch.

Reporting note: the three advisories, their GHSA identifiers and upstream React references, the affected configurations, the sharp workaround, the no-workaround instruction and the September-postponement context were read first-hand from Vercel’s 14 October 2026 Next.js security blog. The CVE-2026-96889 mechanism, CWE-416, CVSS 3.1 vector, publication date, source and status were read first-hand from the NVD 2.0 API; the next release timestamps (15.5.28, 16.4.1, 16.4.2) and the per-version sharp optionalDependency ranges were read first-hand from the npm registry API. The GHSA 404 results were measured at time of writing. Nothing was installed, no Next.js application was deployed, no SVG payload was crafted and no proof of concept was executed. A Brave Search query returned the vendor blog plus trade-press summaries and CVE mirrors; no independent reproduction was available at the time of writing.

Sources: