As React2Shell (CVE-2025-55182) exploits continue to fly, our research team here at VulnCheck is analyzing attack patterns and artifacts across several different dimensions, from in-the-wild payloads and new public exploits to attacking IP volume and target geolocations. As of Monday, December 8, our Canary Intelligence network is observing hundreds of exploit attempts. The chart below is from shortly before 10 AM ET, and our overall detection volume has already grown by 15-20% since then.
Public proof-of-concept (PoC) exploit code has also proliferated significantly, with valid (if derivative) PoCs now approaching triple digits based on our analysis. Notably, however, the public exploits our team has analyzed all target Next.js applications, not React directly. We expect this to change.
While most of the community focus is understandably on opportunistic exploitation and commonplace adversary profiles (e.g., botnets, malicious Nuclei scanning), the real opportunities for attackers lie in the dynamic nature of exploitation and payload modification, much of which mean reduced visibility and detection capabilities for defenders. This blog contains our Initial Access Intelligence team’s analysis of the React2Shell exploit ecosystem, potential and existing payload variations, and implications for detection and response. For background on this incident, read our emerging threat blog here.
VulnCheck Exploits
As soon as the VulnCheck Initial Access Intelligence team evaluated the patch for CVE-2025-55182, it was clear that the vulnerability was going to have non-trivial downstream impacts. We immediately began attempting to find a path to execution, monitoring Git forges for new PoCs and relevant repositories, and writing detection signatures for specific variants.
From this, the team was able to deliver the following artifacts before the weekend hit (and before the spike in opportunistic exploitation attempts had been fully realized):
- An initial weaponized exploit for the Next.js variant that delivers a reverse shell
- An exploit utilizing the in-memory attack variant
- An additional exploit containing the in-memory webshell variant
- A network scanner for Next.js
- Four network signatures for exploit variants based on real exploitation observations
- A vulnerable Docker container for testing
As of December 9, the team has also added support for two additional exploit variants, with accompanying signatures and PCAPs:
- React Router: Targets experimental RSC functionality (not enabled by default) in the react-router library
- Expo: Targets the Expo framework with experimental support for RSC enabled. This version will enumerate the RSC endpoints and turn exploitation automatic.
The team thought the in-memory exploit variant was particularly nifty and immediately prioritized one of these variants for last week’s Initial Access Intelligence release. Naturally, we wouldn’t be representing ourselves accurately if we didn’t throw some shells around. Below is a Next.js React2Shell payload that hijacks the HTTP prototype and injects the /vfearh path to the web server that executes arbitrary commands like an old-fashioned webshell in memory:
albinolobster@mournland:~/initial-access/feed/cve-2025-55182/webshell$ ./build/cve-2025-55182_linux-arm64 -e -rhost 10.9.49.69 -rport 3000 -ell DEBUG
time=2025-12-05T14:08:09.776-05:00 level=STATUS msg="Starting target" index=0 host=10.9.49.69 port=3000 ssl=false "ssl auto"=false
time=2025-12-05T14:08:09.776-05:00 level=STATUS msg="Generating webshell payload"
time=2025-12-05T14:08:09.776-05:00 level=STATUS msg="Uploading webshell to target"
time=2025-12-05T14:08:19.786-05:00 level=ERROR msg="HTTP request error: Post \"http://10.9.49.69:3000/\": context deadline exceeded (Client.Timeout exceeded while awaiting headers)"
time=2025-12-05T14:08:19.786-05:00 level=SUCCESS msg="Webshell installed!" location=http://10.9.49.69:3000/vfearh
time=2025-12-05T14:08:19.786-05:00 level=STATUS msg="Testing `id`" testurl="http://10.9.49.69:3000/vfearh?z=id"
time=2025-12-05T14:08:19.822-05:00 level=SUCCESS msg="uid=0(root) gid=0(root) groups=0(root)\n"
time=2025-12-05T14:08:19.822-05:00 level=SUCCESS msg="Exploit successfully completed" exploited=true
albinolobster@mournland:~/initial-access/feed/cve-2025-55182/webshell$ curl http://10.9.49.69:3000/vfearh?z=ls%20-l
total 168
-rw-r--r-- 1 root root 77 Dec 4 23:41 jsconfig.json
-rw-r--r-- 1 root root 92 Dec 4 23:41 next.config.mjs
drwxr-xr-x 172 root root 4096 Dec 4 23:41 node_modules
-rw-r--r-- 1 root root 16384 Dec 4 23:41 notes.db
-rw-r--r-- 1 root root 123663 Dec 4 23:41 package-lock.json
-rw-r--r-- 1 root root 467 Dec 4 23:41 package.json
-rw-r--r-- 1 root root 6028 Dec 4 23:41 seed.sql
drwxr-xr-x 3 root root 4096 Dec 4 23:41 src
We've made the team's in-memory webshell publicly available here: https://github.com/vulncheck-oss/cve-2025-55182
Attack Path Observations
One of the immediately interesting components of React2Shell CVE-2025-55182 vulnerability is the usage of custom React Flight Protocol (RFP) chunking logic and how it enables dynamic exploitation and payloads that are actively being used by attackers. VulnCheck’s Canary Intelligence network uses the signatures our Initial Access Intelligence team developed to identify new React2Shell variants being used directly on the internet; we’ve also been analyzing and categorizing public PoCs for our Exploit Database (XDB) that hand-curates exploit data from Git forges. The combination of these capabilities has allowed us to identify a few patterns across ongoing React2Shell exploitation and payloads being utilized by attackers.
This custom RFP protocol is used for React Server Components (previously React Server Actions) to allow execution of React components and logic on the server side. The reason this vulnerability stands out from similar (common) issues is that it doesn’t rely on a well-documented and tested format; instead, the vulnerabilities relies on a set of chunks that are interpreted by the implementation, along with a collection of model strings that allow for dynamic evaluation of the chunks (that have side effects on the data being sent). This vulnerability stems from the usage of these chunks to override the server-side variable properties and gain control of the underlying JavaScript object.
While on its face this shares a lot of similarities to something like prototype pollution, the use of a custom protocol and a chunk-based structure allows an attacker a few huge advantages in the evasion and post-exploitation department:
- Dynamic generation and obfuscation utilizing the model chunk logic
- Direct interaction with the JavaScript runtime
Since the chunking logic of RFP can use its own internal references, it is possible to do complex recursive references in addition to utilizing the string model `$` prefixed types often on JSON objects sent in the body. In reality, this means that most of the exploitation attempts are generating multiple chunks (often via the NextJS multipart HTTP handling in BusBoy) that then reference each other dynamically and utilize the internal RFP logic to modify behavior. This means that it is possible to do things such as recreate strings or array values that you might see in obfuscated JavaScript directly inside of the RFP requests, but also with the added layer of specialized and unique RFP types.
For example, here is a tiny subset of RFP model types that might be used by attackers to modify the flow the requests:
$Q- Directly references a chunk as a map type, allowing a payload to use a chunk as a map directly without declaring a map and allowing it to be used without a runtime declaration$K- Directly references other form types as chunks, meaning that the attackers targeting Next.js have the opportunity to not just use the single multipart filenames such a0and1that are common, but can reference other forms based on their integer and reference id. For example:$K1_testwill allow access to the1_testform value.$D- Date functions direct values$u- Undefined without directly using theundefinedkeyword- And many many more
From an attacker’s perspective, the post-exploitation story for React2Shell is nearly perfect: a single request that is difficult to detect that results in direct manipulation of the active in-memory runtime that can allow complex manipulation of the back-end server state and access to arbitrary JavaScript runtime actions.
This has led to some interesting observations and variants seen in the wild.
Known Exploits: Current State
The following roughly models the state of PoCs and exploits VulnCheck’s research team has analyzed based on our data corpus: Initial execution-based, in-memory, Unicode escaping in JSON, in-memory webshells, and classic droppers. It’s also likely that we haven’t yet seen the full range of exploit variants and pathways, and may not for some time.
Initial execution-based exploits are the simplest and were the most common immediately following the publication of the first valid PoCs. These often had a similar structure to the maple3142 PoC in that they simply call the NodeJS process and require modules to directly access child_process or similar OS command execution payloads. These can be used to call reverse shells or reach simple OS command sinks that are extremely common in logic exploitation bugs.
This led to the next “staged” style payloads that are very common in simple PoCs and exploitation: droppers. Simply put, these variants just write the second-stage payload to disk and either execute it or drop a backdoor set of files to establish permanent access.
The next logical step is that instead of directly calling system commands, we instead observed payloads starting to use the chunk that evaluates the JavaScript runtime to reside in memory, thus allowing adversaries to conduct activities entirely from the injected-into runtime. This is excellent for attackers because it means they can work without touching disk; it also allows for staging of next-step payloads even in environments without writable disks, which greatly decreases likelihood of leaving artifacts behind. These types of payloads started to appear nearly immediately after the first real PoCs were published and . This attack variant was one of the first variants our team created to bypass rules looking for simple require or child_process calls, immediately breaking a large subset of early emerging threat rules.
One of the next variants that we saw took advantage of the fact that the RFP chunks were almost uniformly distributed via JSON objects inside of HTTP forms. Since these are just JSON strings, as exploit developers we immediately recognized the value of being able to combine the chunk logic and JSON string handling that occurs prior to the parsing of the RFP logic, allowing pretty much any part of the RFP request to be escaped with Unicode \uXXXX strings to opportunistically mask the specific fingerprints that had already become common. Suddenly, more detection rules and signatures could be bypassed by simply turning resolved_model into \u0072\u0065\u0073\u006f\u006c\u0076\u0065\u0064\u005f\u006d\u006f\u0064\u0065\u006c (and better yet, mixing and matching the Unicode escaping). This also forces network signatures to rely on pattern matching, which is more expensive and also generally a pain.
Attackers love a Weird Machine, and being able to directly modify the running server state allowed for some interesting interactions. The most notable one that we identified was a variant that would modify the NodeJS HTTP server prototype to allow an entirely in-memory webshell. Yes, you read that correctly. By modifying the prototype carefully, the currently running web server would expose an attacker-controlled path that could provide access to code execution on HTTP paths that were not exposed by the application, were not RFP requests, and would persist until the server is restarted and the Node HTTP prototype is reloaded. This is a nightmare for detection capabilities. Suddenly it was possible to send a single request that, if not caught by detections from the initial request, provided access to code execution on arbitrary attacker-controlled paths with low likelihood of detection.
For a creative attacker, the opportunities suddenly become limitless. We did some whiteboarding and came up with some a few ideas for potential payloads: hooks directly in the TCP handling for Node, entirely in-memory bi-directional encrypted shells, self-modifying the running server to backdoor the server runtime, hiding an in-memory webshell that simulates attacking non-JavaScript behavior by making it look like common drive-by webshells (that will subtly respond to an attacker), injection into Git hooks, and the list goes on. For defenders, this means that “look for RFP requests” may no longer be an effective strategy, and instead will have to shift to “has anyone ever sent an RFP request?”
The Before Times: Prior to Real PoCs
In the initial hours after CVE-2025-55182 was disclosed, there was a flood of wrong PoCs and repositories based on automated analysis or LLM-generated code. This serves as an interesting case study in how usage of these tools can lead to inaccurate information and a breakdown in detection quality that makes organizations less secure than they would be if they did not have false information.
The widely circulated ejpir/CVE-2025-55182-research repository now states that it is a research project driven by Claude. Unfortunately, during the initial hours of the incident, this was one of the first public repositories to surface; at the time, not only did it not contain a warning about AI-generated code, it actually specified that “This is the **real working POC** using actual `react-server-dom-webpack@19.0.0` vulnerable code.” In hindsight, the PoC and code are obviously wrong, but at the time, that repo was one of the only publicly available PoCs that looked like it could be legitimate — and it quickly became clear that people believed it was valid without any evidence that the code path reached the vulnerable components.
Many reputable organizations and security providers quickly jumped at the first available piece of information that looked like it could potentially be legit; security firms used it as a basis for signatures and fingerprints, researchers used it for copycat PoCs, and bad information was spread far and wide as many began (incorrectly) looking for vm#runInThisContext rather than looking for the RFP data chunks. VulnCheck researchers were actively working on this vulnerability at the time and quickly determined that the exploit and application was contrived to the point of not being real. It also did not match any of the patterns that were available in the fix.
Lachlan Davidson, the original vulnerability discoverer, eventually posted a warning on the React2Shell website about invalid PoCs, particularly “anything that requires the developer to have explicitly exposed dangerous functionality to the client,” including PoCs using vm#runInThisContext, child_process#exec, and fs#writeFile. Unfortunately, it’s hard to put the genie back in the bottle in today’s vulnerability data ecosystem, and as a result organizations may have thought they were protected based on AI-generated code that got picked up as true without any real vetting or validation.
Conclusion
React2Shell exploitation is ongoing and is likely to have a long tail. The VulnCheck team has noted several exploit variants already, and we anticipate that others will be released as researchers and adversaries explore pathways for RCE. Public PoCs are widely available but are so far largely targeting Next.js applications, which are an important attack vector but shouldn’t be considered the only options. Organizations should consider variants and possible payload modifications when building their detection strategies, especially since the nature of the vulnerability gives adversaries access to a wide range of hard-to-detect post-exploitation options.
About VulnCheck
VulnCheck’s research team tracks real-world exploitation, attacker infrastructure, and exploit workflows using our Canary Intelligence, Exploit & Vulnerability Intelligence (EVI), and IP Intelligence datasets. For more research like this check out our blogs, The Mystery OAST Host Behind a Regionally Focused Exploit Operation, XWiki Under Increased Attack and Fortinet FortiWeb Exploitation Hits Silently Patched Vulnerability.
Sign up for the VulnCheck community today to get free access to our VulnCheck KEV, enjoy our comprehensive vulnerability data, and request a trial of our Initial Access Intelligence, IP Intelligence, Canary Intelligence, and Exploit & Vulnerability Intelligence products.