China-Nexus Hackers Rapidly Exploit React2Shell Vulnerability

Chinese state-nexus cyber operators moved with exceptional speed to exploit the React2Shell vulnerability (CVE-2025-55182) immediately after its public disclosure on December 3, 2025. Telemetry collected from AWS MadPot sensors, Sonaris active defense systems, and broad internet scanning indicates coordinated probing and exploitation attempts within hours. The activity was traced to infrastructure tied to Earth Lamia, Jackpot Panda, and multiple unattributed clusters exhibiting patterns consistent with Chinese state-linked intrusion workflows. The vulnerability represents one of the most impactful remote code execution threats affecting modern JavaScript server environments due to its reach across React, Next.js, and the React Server Components ecosystem.

React2Shell stems from unsafe deserialization inside the React Server Components protocol. RSC is responsible for translating client component requests into server actions by encoding server function calls into structured payloads. In affected versions, the RSC decoder fails to sufficiently constrain attacker controlled inputs, allowing malicious payloads to influence server execution paths. Because these decoding routines run before authentication checks in many frameworks, a single crafted HTTP request can trigger remote code execution in unpatched environments.

Technical Origin of React2Shell

The vulnerability was identified by researcher Lachlan Davidson and disclosed to Meta on November 29, 2025. React’s RSC implementation uses a binary serialization format to transfer metadata and execution instructions between client and server. When a client triggers a server action, React encodes the request into a protocol payload that includes model references, component identifiers, argument types, and data. The server attempts to deserialize these payloads back into executable structures. The flaw occurs during the decoding of model entries where untrusted values can cause React to instantiate objects or invoke handlers in unexpected ways.

In the vulnerable versions of RSC, the parser uses a trust-forward design pattern where internal helper functions assume upstream validation has occurred. When attacker crafted data is passed into these functions without sanitization, certain payload combinations cause React to traverse unsafe code paths. This allows arbitrary values to be interpreted as dynamic imports, function references, or runtime expressions, providing a path to execution of arbitrary commands through server side adapters that interface with the file system or process execution layers.

Additional analysis shows that the vulnerability resembles classic unsafe deserialization issues in frameworks that load JSON, pickled objects, or serialized classes without strict type enforcement. In this case, the RSC protocol’s flexibility inadvertently introduced an attack vector where run time type interpretation becomes attacker influenced.

Why Server Functions Were Not the Only Problem

Many organizations initially believed that React2Shell only affected applications explicitly using React Server Functions. However this is incorrect. Any application with React Server Components enabled inherits the vulnerable RSC decoder. Even if developers do not register server functions, the server still loads and interprets RSC payloads for pre-rendered components, progressive data streams, and hydration sequences. This makes the vulnerability far broader than applications intentionally using server function endpoints.

Frameworks like Next.js integrate RSC deeply into their routing, data fetching, and rendering models. As a result the vulnerability became a supply chain level issue affecting entire ecosystems regardless of whether projects directly implemented advanced server features.

Downstream Impact Across Major Frameworks

The following dependencies were confirmed affected due to their use of RSC:

• Next.js versions 15.x and 16.x using App Router
• React Router unstable RSC APIs
• Waku
• Redwood SDK
• Expo configurations leveraging RSC support
• Bundler integrations including Parcel RSC, Vite RSC, Turbopack RSC pathways

Because many of these frameworks package RSC modules internally, developers may not realize their dependency tree includes vulnerable code. Even older projects can become vulnerable if build tools automatically upgrade transitive dependencies or if plugin ecosystems silently enable RSC through default settings.

Chinese Threat Groups Operationalize the Vulnerability

Within hours of disclosure, Chinese operators began issuing crafted RSC payloads against publicly exposed endpoints. AWS MadPot recorded activity from multiple Chinese clusters simultaneously, including infrastructure tied to known groups such as Earth Lamia and Jackpot Panda. These groups have a long history of exploiting newly disclosed vulnerabilities in web applications, VPN devices, cloud platforms, and authentication gateways.

Exploitation attempts followed a recognizable pattern. Initial probes used malformed payloads to trigger diagnostic errors. These errors reveal subtle details such as server version, module resolution behavior, code path traversal, and stack trace fragments. Once an endpoint confirmed the presence of the vulnerable RSC decoder, operators escalated to payloads intended to influence the deserialization path toward code execution.

One notable cluster performed more than one hundred requests over fifty two minutes, repeatedly modifying payload structure to improve exploit reliability. Observed payloads attempted to trigger the invocation of fs read operations, process execution calls, and dynamic import chains. Several requests attempted to write files to the tmp directory or read the passwd file. These attempts confirm direct efforts to achieve post exploitation footholds after RCE was triggered.

Public Proof of Concept Code and Attacker Adaptation

The rapid release of multiple proof of concept repositories on GitHub created significant noise. Many PoCs were incomplete or technically incorrect, often registering dangerous modules manually or misrepresenting RSC behavior. Despite the flaws, Chinese operators used these PoCs as a starting point.

Their approach leveraged high volume testing rather than relying on precision. Even unsuccessful exploit attempts can yield valuable intelligence. For example:

• Error traces can reveal which RSC parsing functions were reached.

Attackers used this information to refine payload structures and identify targets running default configurations more susceptible to exploitation.

Attack Flow and Execution Mechanics

A standard RSC attack chain observed in the wild follows these steps:

1. Discovery

Attackers scan for endpoints exposing RSC behaviors. Indicators include specific response headers, hydration markers, and RSC specific JSON model structures.

2. Capability Testing

Attackers send benign malformed RSC payloads to test the server’s behavior. Servers running patched versions return consistent failure responses. Unpatched servers reveal more verbose or unexpected error data.

3. Serialization Manipulation

Attackers craft a payload where controlled values are passed into model entries that influence object resolution or function mapping. The goal is to trigger a code path that resolves to a server side function exposed indirectly through framework behavior.

4. RCE Trigger

Once control is achieved, payloads trigger file reads, process execution calls, or arbitrary module loading. In Node.js environments these often map to the child process or file system interfaces.

5. Post Exploitation

Attackers attempt to access environment variables, cloud credentials, secret keys, or internal APIs. In several cases attackers attempted to write sentinel files for persistence testing.

Infrastructure Linked to Chinese Activity

• 206[.]237.3.150 associated with Earth Lamia
• 45[.]77.33.136 associated with Jackpot Panda
• 143[.]198.92.82 associated with Chinese anonymization networks
• 183[.]6.80.214 associated with hands on exploitation attempts

The variety of clusters involved suggests a coordinated or parallel exploitation effort rather than activity from a single group.

Why React2Shell Represents a High Severity Threat

The significance of React2Shell is tied to several factors. React Server Components are deeply embedded in modern frontend frameworks and not always clearly exposed in application configurations. Organizations may not be fully aware that their projects are running server side logic. Because the flaw allows remote execution before authentication checks, it is particularly attractive to state linked operators focused on stealthy entry points. JavaScript environments often contain rich metadata including environment variables and deployment secrets that can grant broader cloud access. These factors create opportunities for long term espionage operations rather than simple one off intrusions.

Detection Guidance and Immediate Recommendations

The only reliable long term mitigation is to upgrade to patched versions of React and all dependent frameworks. Temporary rule based protections can reduce opportunistic scanning but cannot neutralize deeper logic flaws. Organizations should audit web server logs for suspicious POST requests containing next action or rsc action id headers or payloads using the dollar at syntax pattern. Additional indicators include unexpected creation of Node.js subprocesses, unauthorized file writes in system directories, or attempts to access sensitive files such as passwd.

Organizations running vulnerable versions should review dependency trees to identify indirect RSC imports. In complex build systems transitive dependencies can silently introduce vulnerable code paths. Because exploitation attempts began within hours of disclosure, organizations should assume that any internet facing RSC capable server has already been targeted and should validate system integrity accordingly.