Notifications
Clear all
Topic starter
20/08/2026 5:45 pm
TL;DR: CVE-2025-55182, also called React2Shell, is a critical unauthenticated remote code execution flaw in React Server Components that was being exploited in the wild within days, with CyCognito reporting that about 18% of externally exposed assets in its analysis were vulnerable. The case shows that dependency visibility, external discovery, and fast rebuild-and-redeploy workflows now matter as much as patching itself.
NHIMG editorial — based on content published by CYCOGNITO: analysis of CVE-2025-55182, also known as React2Shell
By the numbers:
- Roughly 18 percent of externally exposed assets in CyCognito's analysis were running vulnerable React Server Components affected by CVE-2025-55182.
- By December 5 2025, CISA had added CVE-2025-55182 to its Known Exploited Vulnerabilities list, confirming active exploitation in the wild.
- About 63 percent of the assets vulnerable to CVE-2025-55182 sat behind a WAF, while about 33 percent had no WAF protection.
Questions worth separating out
Q: What fails when a React Server Components denial-of-service flaw is exposed on public endpoints?
A: The failure is usually operational, not authentication-related.
Q: Why do externally exposed applications make framework vulnerabilities more dangerous?
A: Because internet-facing apps shrink the time between disclosure and exploitation to minutes or hours, not days.
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
- Inventory every externally reachable React and Next.js deployment Map subsidiaries, cloud accounts, forgotten test systems, and shadow deployments that use React Server Components or embedded RSC pipelines.
- Rebuild and redeploy only from patched dependency versions Confirm all builds reference the fixed React Server Components packages and the related framework releases, then update CI/CD templates so vulnerable versions cannot be reintroduced.
- Use compensating controls as temporary containment Deploy WAF rules for malformed or suspicious RSC Flight payloads, tighten access to internal or administrative routes, and reduce backend privilege where the application can touch sensitive systems.
What's in the full analysis
CYCOGNITO's full report covers the operational detail this post intentionally leaves for the source:
- Per-asset exposure breakdowns showing which external systems were most likely to run vulnerable React Server Components
- The exact rebuild and redeploy sequence for affected React and Next.js applications
- Observed mitigation patterns, including WAF deployment choices and rollback lessons from the global outage
- A prioritisation model for public applications, SaaS environments, and systems that can reach internal APIs or secrets
👉 Read CYCOGNITO's analysis of CVE-2025-55182 and exposed React applications →
React2Shell exposure: what it means for external attack surface control?
Explore further
20/08/2026 6:28 pm
External discovery has become a security control, not just an inventory exercise. React2Shell shows that attackers do not care whether a vulnerable framework was intentionally deployed or buried in a transitive dependency. If the application is externally reachable, it is part of the attack surface. The practical conclusion is that exposure-aware inventory must sit alongside patch management, especially for internet-facing applications that can touch sensitive backend systems.
A few things that frame the scale:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: Who is accountable when a vulnerable dependency stays unpatched?
A: Accountability should sit with the service owner, the platform owner, and the security function that approved the exception or missed the escalation. If remediation stalls, organisations should be able to identify whether the failure was due to ownership, tooling, testing, or privilege governance.
👉 Read our full editorial: React2Shell exposure shows why external discovery must lead remediation
