Topic starter
07/06/2026 8:41 pm
TL;DR: A critical CVSS 10.0 RCE flaw in React Server Components and Next.js lets an unauthenticated attacker trigger server-side code execution with a crafted HTTP request, affecting common production frameworks, according to Oligo Security. Static inventory alone is not enough; teams need runtime evidence of what is actually executed.
Editorial analysis by NHI Mgmt Group, based on content published by Oligo Security: “React & Next.js CVE-2025-55182 / 66478 RCE: Affected Versions, Exploit Details & How to Protect Your Apps”.
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 runtime checks matter more than package inventories for this flaw?
A: Because package inventories show presence, not execution.
Q: What signs suggest a framework deserialization flaw is being exploited?
A: Look for unexpected request patterns hitting Server Function endpoints, abnormal deserialization stack traces, and code paths that should not be reachable from public traffic.
Practitioner guidance
- Patch vulnerable React and Next.js versions first Move affected React packages and Next.js deployments to the fixed releases named in the advisory, and prioritise public-facing services that expose Server Components or server actions.
- Verify runtime execution paths before triage Confirm whether vulnerable components are actually loaded and executed in production, because static scans alone cannot prove exploitability for framework deserialization flaws.
- Search for public Server Function endpoints Inventory exposed endpoints that accept RSC payloads, especially where unauthenticated HTTP requests can reach server-side deserialization logic.
Bottom line: This vulnerability shows how unsafe deserialization in framework internals can turn a single request into server-side code execution.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 days ago by NHI Mgmt Group
08/06/2026 8:20 am
Runtime evidence is the new control plane for framework risk. Static inventory tells teams what is present, but not what is actually executing in production. This vulnerability shows why package presence, build metadata, and repository scans can all overstate or understate exposure. Practitioners need a governance model that privileges live execution evidence when deserialization flaws can be reached through ordinary request paths.
A question worth separating out:
Q: What should teams do when a widely used JavaScript framework RCE appears?
A: Treat it as an exposure-verification problem as well as a patching problem. Upgrade to fixed versions, identify which services actually execute the vulnerable framework paths, and isolate public-facing applications first. The priority is to reduce blast radius where the vulnerability is both present and reachable.
👉 Read our full editorial: Critical React and Next.js RCE exposes runtime deserialization risk
This post was modified 3 days ago by NHI Mgmt Group