Skip to content
← All articles

The two Next.js fixes September promised have landed

Oct 19, 2026 · Web Development · 3 min

·By Dimitri Pisarev

On 14 October Next.js shipped the security update it postponed in September: 16.4.1 and 15.5.28 close the critical remote code execution in use cache and the Server Actions denial of service that sat pending upstream coordination, and they add a fix for a second critical in the image optimization path. Both lines are affected, and both have patches.

Which of the three flaws can reach your app?#

The postponed critical, GHSA-673q-mjm6-r5xr: unauthenticated RCE in applications using App Router with Cache Components, firing when a use cache function returns multiple typed arrays. The upstream advisory sits with React as GHSA-xqc2-xf4c-x3h3, and The Hacker News places the affected react-server-dom packages between 19.0.0 and 19.3.0. Next.js names no workaround and asks for an immediate upgrade even where an application defines no such functions.

The new critical, CVE-2026-96889 / GHSA-2464-fhr4-w9xw: a memory vulnerability in an upstream library behind the Image Optimization API becomes exploitable when Next.js runs on glibc-based Linux and SVG files enter the pipeline. The named workaround is sharp at 0.35.5 or newer, and upgrading Next.js pulls a fixed sharp automatically. The Hacker News adds the context around it: reported by Rafael B. Dias through Vercel's Open Source Bug Bounty, fixed upstream in librsvg 2.63.2, and scored two ways, Red Hat at 7.8 while Next.js lists it critical.

The postponed high, GHSA-p3m5-59mp-jv5r: crafted requests against App Router applications that define at least one Server Action can pin a process at full CPU until it stops answering. Applications on Pages Router, or without Server Actions, are not vulnerable.

Running the advisories against this site#

This site is the statically prerendered Next.js 16 build from the Lighthouse write-up, exact-pinned, self-hosted on a glibc VPS. It ran 16.3.8 since the planned September release, which the September write-up covers, and 16.3.8 sits inside the affected window of the image advisory outright: greater than 16.0.0, at most 16.4.0.

The config answers the other two. No Cache Components and no use cache anywhere, so the RCE has no surface. No Server Actions, so the DoS misses by its own condition line. The OG images render through ImageResponse from next/og, and no code path feeds an SVG into the optimizer, but sharp still rides in the tree through Next itself, and this repo's lockfile carried 0.35.4: one patch release below the fix, on the exact platform class the advisory names.

The upgrade took one command today: npm install --save-exact next@16.4.1. sharp moved to 0.35.5 on its own, exactly as the advisory promises. 32 tests across 4 files came back green, and the production build ran clean on the first pass. From patch release to this site: four days. The same window in September was fourteen.

The audit gap and the image pipeline#

Two details reach beyond this release. The use cache critical exists only as a GHSA identifier, with no CVE attached at disclosure, and The Hacker News checked: npm audit stayed silent on it as of 15 October. A dependency scanner was not the discovery channel for the most severe flaw in the batch, so the advisory feed stays on the monitoring list.

And this is the third image-processing RCE since August by The Hacker News' count, after libheif in the AVIF path and the Satori flaw in next/og that September's out-of-band release fixed. The pattern for anyone self-hosting: the image pipeline is a recurring entry point, sharp rides in as somebody else's dependency, and its version deserves the same attention as Next's own.

Two days later the week's other runtime emergency made this one look calm: PHP patched two core RCEs with a demonstrated exploit on default settings and a leak-disrupted disclosure.