Topic starter
21/08/2026 4:55 pm
TL;DR: React2Shell (CVE-2025-55182) allows unauthenticated remote code execution through React Server Components and frameworks such as Next.js, because crafted HTTP requests can abuse unsafe RSC payload deserialization in default deployments, according to Xygeni. The issue turns framework-level trust into a server-side execution path, so patching, SBOM review, and runtime detection now matter more than static dependency checks.
Editorial analysis by NHI Mgmt Group, based on content published by Xygeni: “React2Shell: CVE-2025-55182 and the Next.js RCE Risk”.
Key questions
Q: What breaks when unsafe deserialization exists in a React Server Components implementation?
A: Unsafe deserialization lets attacker-controlled payloads influence server-side processing in ways the framework was not meant to allow.
Q: Why do default Next.js deployments increase the impact of React2Shell?
A: Because the vulnerable code path is reachable in standard framework configurations, not only in heavily customised applications.
Q: How do security teams know whether React2Shell-style exposure is actually contained?
A: They need three signals: all deployed builds reference fixed versions, no vulnerable RSC packages appear in compiled artefacts or dependency trees, and logs show no suspicious requests or abnormal outbound activity after disclosure.
Practitioner guidance
- Patch vulnerable React and Next.js packages immediately Upgrade affected React server packages and framework releases to patched versions across all environments, including canary and transitive dependencies.
- Scan deployed applications for RSC exposure paths Identify every application using React Server Components, Next.js App Router, or related framework packages, then confirm where Flight payloads are accepted over HTTP.
- Add payload-aware detection for exploitation attempts Alert on malformed RSC Flight payloads, repeated 500 responses on RSC endpoints, and suspicious Next-Action or Next-Router-State-Tree headers.
Bottom line: React2Shell shows that framework-managed deserialization can become a direct server execution path when untrusted HTTP input is accepted without sufficient validation.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
21/08/2026 5:12 pm
Framework trust is now an attack surface, not a convenience layer. React Server Components collapse part of the application boundary into framework-managed serialization and deserialization, which means the control point has shifted from app code to runtime plumbing. That creates a governance blind spot when teams assume framework defaults are safe until custom logic is added. The practitioner implication is to treat default framework data paths as privileged execution surfaces.
A question worth separating out:
Q: What should organisations do first after finding vulnerable React server packages?
A: Prioritise exposure-based remediation, starting with internet-facing applications and then moving through internal deployments, container images, and transitive dependencies. Patch to known fixed versions, validate the software bill of materials, and confirm the affected runtime path is no longer reachable. That sequence reduces exposure before deeper validation work begins.
👉 Read our full editorial: React2Shell exposes unauthenticated RCE across React server apps