Detecting RCE Exploits in React Applications using Host-Based Telemetry

As one might have already heard, a critical RCE vulnerability (CVE-2025-55182) was disclosed in the React Server Components (RSC) protocol. The vulnerability stems from unsafe deserialization of payloads in HTTP requests to Server Function endpoints, potentially allowing unauthenticated attackers to execute arbitrary code on the host.

As there currently is no easy way of determining exploitation, Nerium set out to create detection rules. This ultimately resulted in two new host-based detection rules for Microsoft Defender for Endpoint (MDE).

‍

Detection queries & documentation

See the URLs below, which point to our GitHub page containing the detection queries for both Windows and Linux, as well as the detailed documentation.

‍

Detection possibilities for exploitation

Although a web application firewall (WAF) might reduce the risk of exploitation, it does not fully circumvent exploitation. WAFs can in fact be bypassed, as is shown in multiple publications relating to this vulnerability. [1] [2]
‍

Host-based detections

As signature-based detection methods are deemed unreliable, Nerium set out to create detection logic, based on available host-based logging. As a large part of Nerium’s customer base uses MDE, Nerium opted for testing the exploitation using a system with MDE installed. This only works however, when MDE is installed on the server which runs the React instance. During testing it became apparent that MDE currently does not alert out-of-the-box on any direct exploitation of the vulnerability itself, but does have telemetry available.
‍
Nerium ultimately developed two separate queries for Linux and Windows respectively. These queries are designed as a detection rule, but can be used as a one-time hunting query as well.
‍

How do the queries work?

High-over, both queries look for unexpected shells created by the NodeJS process.
The test were performed against two vulnerable React webservers using a publicly available vulnerable template React server [3]. A published exploit script [4] was used to perform the vulnerability on the two vulnerable servers.
‍
After testing, it turned out that the shells which are spawned by the NodeJS process are quite static, as can be seen in the screenshots. This means that there is an opportunity for detection.
On Linux systems the shells that are spawned, consistently start with “/bin/sh -c”. For Windows hosts these shells start with “cmd.exe /d /s /c”.
‍

‍

Known blind spots

Unfortunately, Defender lacks telemetry with regards to direct JavaScript execution. This means that pure JavaScript scripts won't be picked up by the queries. However, if the JavaScript spawns a new process or calls system commands, it will spawn a shell and will be covered by this detection.
‍

Possible False Positives

During testing and running the queries in our own environment we did not observe any similar shell activity that was legitimate. Still it could be that webserver itself runs legitimate commands spawned via a shell.
‍