A newly disclosed remote code execution bug in React Server Components, nicknamed React2Shell and tracked as CVE-2025-55182, is rapidly emerging as a top concern for teams responsible for identity-centric applications and data stores.
The React team disclosed the flaw on December 3, describing it as an unauthenticated RCE bug in how React decodes payloads sent to server function endpoints via the Flight protocol. The issue affects React 19.x when using Server Components, including packages such as react-server-dom-parcel, react-server-dom-turbopack, and react-server-dom-webpack. Patched versions have been released as 19.0.1, 19.1.2 and 19.2.1, and the associated Next.js advisory references overlapping impact for applications using the App Router.
Within days of disclosure, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2025-55182 to its Known Exploited Vulnerabilities catalog after confirming active exploitation. SecurityWeek and other outlets report that multiple threat actors, including China-linked groups identified by AWS, are now targeting vulnerable React and Next.js deployments at scale. KEV inclusion brings federal remediation deadlines and sends a strong signal to enterprises that unpatched instances should be treated as high-risk.
For identity and access systems, the concern is not a front-end UI glitch but deep server-side compromise. React2Shell allows attackers to send crafted payloads that are deserialized on the server, execute arbitrary code and potentially pivot into adjacent services. Any environment where React Server Components sit in front of authentication flows, customer portals, identity data APIs, or management consoles for identity providers and access platforms becomes a prime target. Once an attacker has shell access on a server handling login or profile traffic, they can attempt to harvest session tokens, steal API keys, access secrets used by OAuth/OpenID Connect infrastructure, or exfiltrate identity data and logs.
Cloud providers are treating this as a first-order risk for internet-facing workloads. Google’s security and identity engineering teams, for example, have published detailed guidance on using Cloud Armor to block exploit traffic, recommending that organizations first deploy new rules in preview mode to validate impact before enforcing them in production. Other vendors and CERTs have released similar recommendations or managed WAF rulesets tuned to the exploit patterns.
At the same time, third-party risk specialists are warning that the blast radius is not limited to first-party sites. Black Kite’s recent analysis highlights React2Shell alongside issues in analytics services such as Mixpanel, noting that many organizations outsource logging, analytics and behavioral telemetry for identity events to SaaS providers built on modern JavaScript frameworks. A compromise in one of these third parties could expose identity-rich telemetry, cross-site identifiers and behavioral signals that are increasingly fed into fraud and risk engines.
For CISOs and identity architects, responding to React2Shell means going beyond a simple library update and treating this as a direct threat to identity infrastructure. The first priority is to identify where React 19 Server Components or Next.js App Router are in use, with special attention to applications that handle login, profile management, identity APIs or administrative consoles. Those systems should be moved onto patched versions as quickly as possible and subjected to targeted testing to make sure nothing in the authentication flow has been broken in the process.
At the same time, organizations will want to bring their edge and application security controls into the response. That typically involves rolling out updated web application firewall rules or managed protections supplied by cloud providers and security vendors, then running them in a staged or preview mode before enforcing them in production. The goal is to filter out exploit traffic associated with React2Shell without disrupting legitimate identity flows, which makes careful monitoring during rollout essential.
The vulnerability also highlights the need to revisit how secrets are managed around identity systems. If signing keys, OAuth or OpenID Connect secrets, API tokens or other sensitive credentials are stored on the same servers that are exposed to React2Shell, an attacker who gains remote code execution will have a much easier path to escalate into full identity compromise. Moving those secrets into hardened vaults and tightening access policies reduces the potential blast radius.
Finally, React2Shell should prompt a renewed look at third-party risk. Many organizations depend on SaaS analytics, logging and behavioral telemetry tools built on the same JavaScript frameworks that are now being targeted. If those providers suffer a breach, attackers could gain access to identity-rich telemetry and cross-site identifiers that feed into fraud and risk engines. It is reasonable for enterprises to ask their key vendors how they are addressing CVE-2025-55182, what remediation steps they have taken, and how they are monitoring for exploitation attempts. Treating React2Shell as a core identity security issue, rather than just another web bug, will be critical to keeping account data and trust frameworks intact.
Sources: React, NVD, Google Cloud, SecurityWeek, Black Kite
—
By Cass Kennedy
