Notifications
Clear all
Topic starter
18/08/2026 2:42 pm
TL;DR: A critical unsafe-deserialization flaw in React Server Components and Next.js lets a single crafted HTTP request trigger pre-auth arbitrary code execution on exposed RSC endpoints, per Apiiro's analysis. The issue turns app-framework internals into an internet-facing attack surface, so exposure mapping, rapid patching, and temporary endpoint controls now matter as much as CVSS.
NHIMG editorial — based on content published by Apiiro: React Server Components and Next.js critical RCE disclosure
By the numbers:
- The issue has been rated CVSS 10.0, indicating critical severity.
- React RSC packages 19.0.0, 19.1.0, 19.1.1, and 19.2.0 are affected in the reported flaw.
- Next.js stable 15.x and 16.x are affected when App Router and RSC features are enabled.
Questions worth separating out
A: The main failure is that untrusted input can reach privileged server logic before access controls do their job.
Q: Why do framework-level RCE flaws matter more when apps are internet-facing?
A: Internet exposure turns a code-level flaw into an immediate entry point for attackers.
Q: How can security teams tell whether an application dependency is actually reachable?
A: They need service-level inventory, not just a package scan.
Practitioner guidance
- Patch affected React and Next.js versions immediately Move affected React RSC packages to the patched releases and upgrade Next.js workloads using App Router or RSC features to the vendor-provided fixed versions.
- Inventory every RSC-enabled service and route Build a dependency-to-service map for react-server-dom-* packages, then identify which environments are exposed externally and which handle sensitive data.
- Apply temporary request filtering and exposure reduction Add WAF rules for suspicious RSC Flight payloads, monitor for high-entropy serialized frames and server function errors, and restrict network access to the highest-risk applications while patching is in progress.
What's in the full analysis
Apiiro's full analysis covers the operational detail this post intentionally leaves for the source:
- Exact patched versions for React RSC packages and Next.js release lines affected by the flaw
- Inventory and prioritisation workflow for finding vulnerable react-server-dom-* dependencies across repos and services
- Temporary WAF and monitoring guidance for malformed RSC Flight payloads during emergency remediation
- Suggested workflow steps for raising and tracking remediation work items across teams
👉 Read Apiiro's analysis of the React RSC and Next.js pre-auth RCE flaw →
React server components RCE: are your exposed endpoints ready?
Explore further
18/08/2026 3:26 pm
This is an application boundary failure, not just a vulnerability count. The important issue is that framework internals accepted attacker-controlled structure before normal trust checks could intervene. That means inventory, exposure mapping, and patch governance matter as much as code-level remediation. Practitioners should treat framework parsing paths as part of the control plane for application access.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
A question worth separating out:
Q: Who is accountable when a critical framework flaw is exposed in production?
A: Accountability usually spans application owners, platform engineering, and security operations. The application team owns patching and code changes, platform teams manage deployment and exposure, and security teams coordinate triage and containment. Clear ownership matters because critical RCEs require rapid decisions on upgrades, temporary restrictions, and recovery validation.
👉 Read our full editorial: React RSC deserialization flaws expose a critical pre-auth RCE path
