Next.js RCE Patch: Why Two 9.5 CVSS Flaws Deserve Immediate Attention

As reported by The Hacker News, Vercel released an out-of-band Next.js patch on October 14, 2026 addressing two critical unauthenticated remote code execution vulnerabilities (CVSS 9.5 each) and one high-severity denial-of-service issue. From Shield53's perspective, this is a meaningful event not because Next.js is uniquely vulnerable, but because the attack surface it exposes — server-side rendering, image optimization, and Server Actions — is now pervasive across modern web stacks.

What This Means in Practice

The two RCE paths are conceptually different but operationally similar: an unauthenticated attacker sends crafted input to a publicly-exposed Next.js endpoint and achieves code execution on the host. That is the worst-case scenario for any front-end-adjacent framework, because Next.js applications are almost universally internet-facing and often run with sufficient privileges to pivot into adjacent infrastructure.

Flaw 1: React Server Components cache deserialization (GHSA-673q-mjm6-r5xr)

Flaw 2: librsvg memory corruption via sharp (CVE-2026-96889 / GHSA-2464-fhr4-w9xw)

• Severity: Critical (CVSS 9.5)
• Affected: Next.js 10.0.0–15.5.27 and 16.0.0–16.4.0 on glibc-based Linux where attacker-supplied SVGs reach sharp
• Patch: Next.js 16.4.1 or 15.5.28 with sharp 0.35.5+

The SVG flaw is the more broadly exposed of the two: any Next.js deployment on glibc-Linux that enabled dangerouslyAllowSVG or uses next/og on the Node runtime is at risk. The name of that setting should already tell defenders everything they need to know about its risk profile.

Flaw 3: Server Actions DoS (GHSA-p3m5-59mp-jv5r)

• Severity: High
• Affected: App Router apps with at least one Server Action, Next.js 13.0.0–15.5.27 and 16.0.0–16.4.0
• Patch: 15.5.28 / 16.4.1

Who Is Most Exposed

Enterprises running Next.js behind edge CDNs may assume their origin is protected, but both RCE paths require only a crafted HTTP request to the origin — not bypass of edge logic. The most exposed groups are:

• Marketing and e-commerce sites that accept user-uploaded SVG assets
• Applications using next/og for dynamic social image generation on Node runtime
• Internal tooling built on Next.js 16 with Cache Components enabled
• Multi-tenant SaaS where one customer's SVG upload could compromise the shared worker

Shield53 Recommendations

Immediate Actions (within 24 hours)

1. Patch now. Upgrade to Next.js 16.4.1 (Active LTS) or 15.5.28 (Maintenance LTS). Update sharp to 0.35.5+ in lockfile.
2. Inventory exposure. Search codebases for dangerouslyAllowSVG, next/og, and use cache to prioritize remediation sequencing.
3. Disable SVG optimization at the WAF/edge if patching is delayed. Strip <svg> content-type at ingress or block the optimizer route.
4. Contain the runtime. Ensure Next.js workers run as non-root, in a restricted namespace, with egress filtering. RCE is only useful to an attacker if it can reach something.

Detection

• Monitor for anomalous process spawns from the Next.js worker (node, sh, curl, wget)
• Alert on unexpected outbound connections from image-optimization containers
• Log SVG uploads with oversized <script> or deeply nested element structures as suspicious

Longer Term

• Re-evaluate whether dangerouslyAllowSVG is ever appropriate in production — the naming is a warning, not a permission slip
• Move image optimization into a sandboxed microservice with its own blast radius
• Track upstream librsvg and sharp advisories independently of Next.js, since transitive CVEs often arrive before the integrator discloses

These flaws are a reminder that modern full-stack frameworks collapse multiple attack surfaces — rendering, caching, server logic — into one process. Treating them as front-end concerns understates the risk. Patch tonight, contain the runtime, and revisit whether your architecture gives image processing the isolation it deserves.