Topic starter
02/08/2026 9:41 am
TL;DR: React2Shell, a critical CVE-2025-55182 in React Server Components, allows unauthenticated remote code execution through unsafe deserialization in the Flight protocol, with active exploitation observed within hours of disclosure according to StackHawk. The episode reinforces that dependency awareness is not the same as exploitability, and runtime validation now matters as much as patching.
Editorial analysis by NHI Mgmt Group, based on content published by StackHawk: “React2Shell: What To Know About The Critical React RCE Vulnerability”.
By the numbers:
- React2Shell was published as CVE-2025-55182 and rated Critical with a CVSS score of 10.
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 untrusted payloads in server-side frameworks create such a high risk?
A: Because the application is no longer just reading data.
Q: How do security teams know if a framework exploit has already been attempted?
A: Look for unusual request patterns around the vulnerable protocol, repeated unauthenticated requests, malformed payloads, and errors that appear only on specific server routes.
Practitioner guidance
- Patch exposed React Server Components immediately Move vulnerable React and Next.js versions to the patched releases as soon as they are available, starting with internet-facing applications and shared front-door services.
- Trace transitive framework dependencies Review the full dependency tree for react-server-dom packages and any framework paths that inherit the vulnerable Flight deserialization logic.
- Validate exploitability in the running app Use runtime scanning to test whether the deployed application is actually reachable through a malicious Flight payload, then rescan after patching to confirm the exposure is gone.
Bottom line: React2Shell turned a server-side deserialization flaw into a critical unauthenticated RCE path, showing how quickly input handling can become code execution when the server trusts Flight payloads.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:35 pm
Deserialization trust is the real control gap here: React2Shell shows that server-side parsing is itself an enforcement boundary, not a neutral plumbing layer. When untrusted input can steer promise resolution and internal parser state, application security is no longer just about input validation at the edges. Practitioners should treat any protocol that deserializes remote objects as a policy-enforcement surface, especially when it can trigger server-side logic.
A few things that frame the scale:
- The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.
A question worth separating out:
Q: What should teams do first when a critical RCE affects an internet-facing web framework?
A: Contain the vulnerable service before assuming patching alone is enough. Isolate exposed workloads, block unnecessary egress, and rotate any secrets the runtime could access. If the application can reach internal APIs, metadata services, or secret stores, treat the host as a potential pivot point and verify whether the exploit was already used.
👉 Read our full editorial: React2Shell shows how deserialization flaws become instant RCE