Next.js Out-of-Band Update Fixes Two Critical Unauthenticated RCEs — One Lives in use cache, the Other in the SVG Image Optimizer
Next.js Out-of-Band Update Fixes Two Critical Unauthenticated RCEs — One Lives in use cache, the Other in the SVG Image Optimizer
Next.js shipped an out-of-band security update on October 14 that fixes two critical vulnerabilities allowing unauthenticated remote code execution, along with a high-severity denial-of-service flaw. Vercel, which develops the framework, rated both code-execution bugs CVSS 9.5. Updates are available in 16.4.1 (Active LTS) and 15.5.28 (Maintenance LTS), and Vercel's guidance is blunt: upgrade now, then rebuild and redeploy.
The first flaw sits in React Server Components caching. When a use cache function returns more than one typed array in an App Router application with Cache Components enabled, an attacker-controlled value transported alongside those arrays can lead to code execution. The Next.js advisory (GHSA-673q-mjm6-r5xr) points to an upstream React advisory (GHSA-xqc2-xf4c-x3h3) covering react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack versions 19.0.0 through 19.3.0. React describes the trigger as "extremely rare cases," but Vercel says there is no known workaround for affected applications and recommends upgrading immediately even if your app has no such function.
The second flaw is a memory bug in librsvg, the library Next.js reaches through the bundled sharp package to render SVG images in the Image Optimization API. On glibc-based Linux, processing a malicious SVG can lead to remote code execution — tracked as CVE-2026-96889 / GHSA-2464-fhr4-w9xw. Two mitigating factors narrow the blast radius: Next.js does not optimize SVG files by default, and serving them through the optimizer requires enabling a setting named, aptly, dangerouslyAllowSVG. The underlying librsvg bug was made public on September 23 and fixed in sharp 0.35.5 (carrying librsvg 2.63.2) on September 27 — but Next.js apps kept bundling the old, affected sharp. The DoS flaw (GHSA-p3m5-59mp-jv5r, upstream React GHSA-h3gv-c5rc-p453) lets crafted requests against App Router applications with at least one Server Action pin the CPU and block processing of further requests in the same process.
Two operational gotchas deserve attention. First, on Next.js 15 the fix can silently fail: 15.5.28 still accepts the older affected sharp 0.34.x, so upgrading over an existing install may leave the vulnerable version in place — you must verify sharp is 0.35.5 or later, or block SVG rendering with sharp.block({ operation: ["VipsForeignLoadSvg"] }). Second, as of October 15 the use cache and Server Actions advisories have no CVE IDs and do not appear in the npm advisory feed, meaning npm audit and dependency scanners will not warn about them.
What Should You Do?
- Upgrade and redeploy — move to next@16.4.1 or next@15.5.28, then rebuild and redeploy. This is the only complete fix for the use cache flaw.
- Verify the sharp version — check that your dependency tree carries sharp 0.35.5 or later, especially on Next.js 15 where the upgrade can leave the old version installed.
- Audit
dangerouslyAllowSVG— if you enabled it, most sites do not need SVG optimization; the workaround for the image flaw is to ensure fixed sharp or block SVG rendering in it. - Do not trust npm audit this week — two of the three advisories carry no CVE, so check the GitHub advisories directly and assume scanners are blind to them.
The WAF Angle
The Image Optimization API is edge infrastructure by another name — it exists to process untrusted content (uploads, remote images, now SVGs) on your servers, which makes it a permanent soft target. SVG deserves special respect: it is XML that can carry scripts and external references, and running it through a server-side renderer is the same class of risk as the libheif image-decoder chain we covered in WordPress. This is also the second time this year the Next.js optimizer has been the dangerous component — the AVIF image optimizer RCE from August lived one setting away too — so the pattern says: put request-shape filtering in front of optimizer endpoints, restrict what content types they will fetch, and treat dangerouslyAllowSVG like the warning label it is. While you redeploy, a WAF rule that blocks SVG requests to image optimizer paths buys back the exposure window the old sharp left open.
