React2Shell exploitation exposes default-vulnerable React applications

At a glance

What this is: This is an analysis of the React2Shell flaw, showing that CVE-2025-55182 can be exploited through default React Server Components deployments with a single crafted request.

Why it matters: It matters to IAM and security teams because application exposure, package inventory, and response speed now determine whether identity-adjacent runtime paths become an unauthenticated entry point.

By the numbers:

• React core receives over 20 million downloads every week, according to NPM Trends data cited by ArmorCode.
• React powers more than 11 million websites globally, according to ArmorCode's analysis.
• Roughly 6.2% of the top 10,000 highest-trafficked sites run React-based applications, according to ArmorCode.

👉 Read ArmorCode's analysis of React2Shell exploitation and immediate response steps

Context

React2Shell is a remote code execution vulnerability in React Server Components that turns a widely deployed application framework into an unauthenticated attack surface. The issue matters because default configurations can be exploitable, which means security teams cannot rely on explicit feature use or developer intent as a safe boundary.

For identity and access programmes, the deeper lesson is inventory and trust. If application components can be compromised before teams even understand where they are used, then access control, secrets protection, and runtime monitoring all depend on software visibility that is often incomplete at the point of attack.

The article frames an urgent application security problem, but the starting position is not unusual. Default-vulnerable packages, delayed patching, and incomplete dependency mapping are common conditions in large enterprises.

Key questions

Q: What breaks when React Server Components are exploitable by a single request?

A: Authentication assumptions break because the attacker does not need valid credentials to reach server-side execution. The first failure is trust in the framework boundary, followed by runtime compromise if the request can trigger code execution. Teams should treat the framework version itself as the security control, not only the surrounding app code.

Q: Why do default-vulnerable frameworks create more risk than custom misconfigurations?

A: Default-vulnerable frameworks expand the attack surface before teams have a chance to configure them safely. That means exposure can exist across many deployments even when developers never enable the risky feature intentionally. In practice, inventory and emergency upgrade paths matter more than local hardening alone.

Q: How do security teams know when timing-based exploitation is actually working?

A: Look for repeated requests that produce consistent, measurable delays tied to changing input values. A real timing attack usually shows a pattern across multiple probes, not a single slow response. Baseline variance matters, so teams should compare response distributions, not isolated timings. When delay thresholds become the only way to distinguish outcomes, the application is already exposing an inference channel.

Q: Who is accountable when a library flaw exposes production applications?

A: Accountability usually spans application owners, platform teams, and security governance because the failure sits in dependency management, deployment control, and runtime monitoring at the same time. Framework and patch owners must identify affected estates quickly, while security teams must enforce emergency remediation and temporary blocking until the exposure is removed.

Technical breakdown

Unsafe deserialisation in React Server Components

React Server Components use the Flight protocol to send structured data between browser and server. In CVE-2025-55182, the server fails to validate attacker-controlled payload structure before processing it, which can let crafted input influence execution logic. That makes the flaw an unsafe deserialisation problem, not a normal application bug. The important distinction is that the attack does not need a valid session or a known user path. It rides on how server components interpret data, which is why default deployments can be exposed even when teams believe they are not using the risky feature set.

Practical implication: validate whether server component support exists anywhere in your dependency graph, not only in code you wrote directly.

Why default Next.js builds become an attack surface

The article notes that a standard create-next-app deployment built for production can be vulnerable without code modification. That matters because security teams often treat risk as a result of custom misconfiguration, while here the dangerous state exists in the default operational posture. Once a package or framework ships with an exploitable pathway enabled by design, inventory and version control become the primary control plane. The exploitation surface is then determined by package version, framework mode, and runtime exposure, not by whether developers intentionally enabled an advanced feature.

Practical implication: map framework versions and build modes to exposure status as part of application inventory and release governance.

Why single-request exploitation changes response priorities

A single crafted HTTP request is enough to trigger remote code execution, which compresses the defender's reaction window. In practice, that shifts value from forensic depth after compromise to pre-exploitation blocking, rapid patching, and runtime detection of suspicious process creation. The article's evidence of command execution attempts, file writes, and process spawns shows that attackers are validating access as they go. That pattern aligns with active exploit chaining rather than opportunistic scanning, which raises the priority of immediate containment controls over post-event review.

Practical implication: use WAF mitigation, patching, and process-level detection together because no single layer is sufficient during the exposure window.

Threat narrative

Attacker objective: The attacker wants arbitrary code execution on exposed React and Next.js servers so they can establish footholds, validate access, and prepare deeper intrusion.

1. Entry occurs when an attacker sends a single crafted HTTP request to a vulnerable React Server Components endpoint using CVE-2025-55182.
2. Escalation follows when unsafe deserialisation allows the payload to influence server-side execution logic and produce remote code execution.
3. Impact is unauthorised command execution, file writes, and live validation of access on application servers, which can lead to broader compromise.

Breaches seen in the wild

• Gladinet Hard-Coded Keys RCE Exploitation — Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Default-vulnerable application components are now a governance problem, not just a patching problem. When a framework is exploitable in its shipped state, security teams cannot depend on developer intent or explicit feature activation as the boundary of risk. That makes software composition, release governance, and emergency patch workflows part of core security governance. Practitioners should treat default-exposed framework behaviour as a standing control gap.

React2Shell shows how application security and identity governance intersect at the runtime layer. Once attackers reach server execution, they can search for tokens, service credentials, and internal trust relationships that were never meant to be reachable from a browser request. That is an NHI governance issue as much as an application flaw, because exposed secrets and workload credentials turn runtime compromise into broader access abuse. Practitioners should tie package exposure to secrets and privilege inventories.

Detection speed now matters as much as vulnerability awareness. The article's reported command execution and file write attempts show attackers moving from proof of access to live exploitation validation. That pattern creates a detection-response latency problem, where defenders lose value if they only learn after compromise is complete. Practitioners should align exposure monitoring, WAF telemetry, and endpoint process signals so the first suspicious request is visible before lateral movement begins.

Cloud-delivered protections help, but they do not replace software lifecycle discipline. The article notes WAF rules and automated protections, yet it also states that those controls are not substitutes for patching. That is the right framing: compensating controls can narrow blast radius, but only version remediation removes the underlying exploit path. Practitioners should use temporary controls to buy time, not to normalise deferred remediation.

Exploit velocity is the new baseline for internet-facing libraries. The attacker playbook now assumes public disclosure will be followed almost immediately by live probing. That raises the bar for asset owners, because the old sequence of disclosure, internal review, and scheduled remediation is too slow for maximum-severity library flaws. Practitioners should build emergency change paths for high-risk dependencies and connect them to identity, secrets, and runtime control reviews.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• From our research: Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• From our research: Ultimate Guide to NHIs , Key Challenges and Risks explains why visibility gaps, sprawl, and over-privilege keep turning exposure into breach impact.

What this signals

React2Shell reinforces a broader exposure-management pattern: if teams cannot see every framework instance, they cannot protect every runtime path. That is why application inventory has become a security prerequisite, not an audit exercise. Where identity and secrets are present in the same runtime, the blast radius of a missed package version can extend well beyond the application tier.

Security teams should expect more exploits that move from disclosure to live probing in hours, not days. The operational answer is to connect dependency intelligence, WAF telemetry, and runtime process signals into one response path so remediation does not depend on manual triage alone.

The governance lesson is that emergency patching must be pre-authorised before the emergency arrives. If change control cannot move a critical framework update quickly, the organisation is already operating outside its risk tolerance.

For practitioners

• Inventory React exposure across the full application estate Trace React, React Server Components, and Next.js dependencies across direct and transitive packages, then mark every production service that can reach the affected versions. Use software bill of materials data and release metadata together so indirect usage does not remain hidden in nested dependencies.
• Patch affected framework versions immediately Move to the fixed React releases and the stable Next.js path described in the article, then confirm the change through deployment evidence rather than ticket closure. Treat this as an emergency remediation path, not a routine sprint item.
• Deploy temporary WAF blocking for exploit patterns Apply vendor-published WAF rules for CVE-2025-55182 while patch rollout is in progress, and verify that the rules are active on every internet-facing endpoint that can serve React Server Components traffic. Keep the mitigation time-bounded and review it daily until remediation is complete.
• Hunt for process and file-creation indicators Review logs for next-action and rsc-action-id headers, $@ request patterns, /tmp file writes, and unexpected child processes spawned by Node.js application runtimes. Correlate those signals with authentication logs and secret access events to identify whether the exploit reached sensitive runtime paths.

Key takeaways

• React2Shell turns a popular framework into an unauthenticated entry point when vulnerable versions remain in production.
• The scale is material because React sits in millions of websites and exploitation began within hours of disclosure.
• The control that matters most is fast estate-wide inventory paired with immediate patching and temporary blocking.

Key terms

• React Server Components: A server-side rendering model that moves part of the React component tree to the server and streams rendered output to the client. Because it runs inside the application trust boundary, flaws in this layer can expose code, secrets, or processing logic rather than only visual behaviour.
• Unsafe Deserialisation: Unsafe deserialisation happens when an application turns untrusted serialized data back into objects without strict validation. In Python, this can become code execution if the format supports callable reconstruction or hidden execution paths. Authentication code should avoid it entirely when processing cookies, sessions, or request data.
• Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
• Compensating Control: A compensating control is a measure that reduces risk when the ideal fix, such as immediate patching or redesign, is not possible. In OT, compensating controls often include session recording, access restriction, and tighter monitoring. They do not eliminate the underlying issue, but they narrow exposure until safer remediation can happen.

What's in the full analysis

ArmorCode's full blog covers the operational detail this post intentionally leaves for the source:

• Affected package and framework version mapping across React, Next.js, and downstream RSC plugins
• Concrete WAF rule guidance and the specific AWS and Google Cloud mitigation references
• Indicator-of-compromise examples for logs, request bodies, and server-side process activity
• ArmorCode's exposure-correlation workflow for finding vulnerable packages across connected scanners

👉 The full ArmorCode post covers exploit indicators, mitigation guidance, and affected package details.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity for practitioners building stronger access control. It helps security teams connect runtime exposure, privilege, and identity lifecycle decisions across modern application estates.