TL;DR: React2Shell, tracked as CVE-2025-55182 and CVE-2025-66478, enables unauthenticated remote code execution through React Server Components and Next.js App Router, with active exploitation and KEV listing raising the urgency for exposed applications, according to FireCompass. The real risk is not just patching a framework version, but stopping a single web-tier foothold from becoming privilege escalation, lateral movement, and identity or cloud compromise.
NHIMG editorial — based on content published by FireCompass: React2Shell (CVE-2025-55182): Pre-Auth RCE in React & Next.js, a Log4Shell-style wake-up call
By the numbers:
- Wiz research indicates roughly 39% of cloud environments they analysed contain React or Next.js versions vulnerable to React2Shell-class issues.
- Recent surveys show over 80% of surveyed developers use React in some form.
- CISA has added CVE-2025-55182 to the Known Exploited Vulnerabilities catalog, setting a remediation deadline of 26 December 2025 for US federal agencies.
Questions worth separating out
Q: What breaks when React Server Components are exposed to unauthenticated traffic?
A: The trust boundary breaks at the server parser.
Q: Why does a pre-auth RCE in a web framework become an identity risk?
A: Because the application runtime often runs with service-account permissions, metadata access, or deployment secrets that function as non-human identity credentials.
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
- Map all RSC-enabled web workloads Identify every React 19 and Next.js App Router deployment, including wrappers and canary builds, then confirm whether React Server Components are actually enabled in production.
- Validate real exploitable paths Use attack-centric testing to determine whether unauthenticated requests can reach the vulnerable Flight protocol handling path, rather than relying on dependency scans alone.
- Restrict runtime identity reach Review what the Node.js process can access, including environment variables, metadata services, mounted secrets, cloud APIs, and internal service endpoints.
What's in the full article
FireCompass' full blog covers the operational detail this post intentionally leaves for the source:
- Version-specific affected and fixed builds for React Server Components and Next.js App Router.
- Attack-path examples showing how a compromised web tier can reach cloud control planes, Active Directory, and CI/CD systems.
- Detection guidance for identifying exposed React and Next.js assets across the external attack surface.
- Playbook details for validating whether a vulnerable endpoint is actually exploitable in your environment.
👉 Read FireCompass' analysis of the React2Shell pre-auth RCE and exposure paths →
React2Shell and pre-auth RCE: what IAM and security teams need to know?
Explore further
React2Shell is not just an AppSec flaw, it is a runtime identity problem. Once server-side rendering code can be reached anonymously, the application process itself becomes the attacker’s entry point into secrets, cloud metadata, and downstream systems. That shifts the control question from front-end patching to runtime privilege containment and service-account governance. Practitioners should treat web workloads as identities with blast radius, not just code to patch.
A few things that frame the scale:
- The ratio of non-human to human identities now exceeds 100:1 in enterprise environments, according to Ultimate Guide to NHIs , Why NHI Security Matters Now.
- Only 44% of developers are reported to follow security best practices for secrets management, according to The State of Secrets in AppSec.
A question worth separating out:
Q: What should teams do first after finding a vulnerable React or Next.js app?
A: Patch the exposed workload, then immediately validate whether the application runtime can reach sensitive identities, metadata, or internal services. That sequencing matters because a fixed package does not remove already-issued credentials or hidden lateral paths. Containment should follow the attack path, not just the CVE ticket.
👉 Read our full editorial: React2Shell shows how pre-auth RCE becomes full-stack compromise