The React2Shell Exploit Surge

At VulnCheck, one of the more Sisyphean tasks our exploit dev team handles is reviewing the constant stream of “exploits” published to developer platforms like GitHub, GitLab, and Gitee. The volume of fake, broken, malicious, and (especially lately) AI-generated slop pretending to be real exploit code is staggering. But it’s also exactly why this work matters. If no one separates signal from noise, defenders and researchers are left with a polluted ecosystem. So for our customers and the broader community, we manually review every exploit before it’s folded into our product and the community-available VulnCheck Exploit Database (XDB).

The volume of CVE-2025-55182 (React2Shell) exploits has been staggering, easily outpacing anything we have had to review before. By noon on December 10, 2025, we had approved 128 GitHub exploits and blocked 127 more. A brutal ratio, but an honest reflection of what gets published during a high-profile CVE.

For those unfamiliar with the saga, the first wave of React2Shell activity was almost entirely useless AI-generated exploits published after the CVE dropped on December 3, 2025. Everything shifted on the afternoon of December 4, when maple3142 published a working proof-of-concept Gist. That single PoC flipped the ecosystem from AI noise to genuine exploit development, and the pace immediately accelerated. We were approving new variants steadily, with developers continuing to publish refinements through the weekend of December 6 and 7.

Approved GitHub Exploits By Publication Date

What VulnCheck Saw in the Data

Naturally, no one is going to review all 128 exploits. A small number get attention, and the rest disappear into the GitHub void. We track star counts to help customers surface the popular ones, and the numbers speak for themselves: 72 repositories have zero stars, and 21 have just one. In most high-profile CVEs, the meaningful work quickly separates itself from the long tail of clones and noise, and React2Shell followed that pattern exactly.

Number of React2Shell Repositories By Star Count

If you go by star count, only a handful of repositories stand out, and three sit clearly above the rest. These are the exploits that most people saw first and that shaped much of the subsequent development:

1. https://github.com/msanft/CVE-2025-55182: One of the earliest public exploits. It now includes a solid writeup and a Python-based implementation.
2. https://github.com/lachlan2k/React2Shell-CVE-2025-55182-original-poc: Exploits developed by the original bug finder, with three JavaScript variants.
3. https://github.com/zack0x01/CVE-2025-55182-advanced-scanner-: A straightforward bash-based scanner.

Interestingly, the three most popular repositories are each written in different languages: Python, JavaScript, and bash. That mix reflects not only the range of developers experimenting with React2Shell, but also the simplicity of the underlying exploit, which makes it easy to reimplement in whatever language someone prefers. This pattern shows up clearly in the overall language distribution.

Repository Count vs. Language

Python dominating the scene is unsurprising. Most public “exploit development” is done by security “researchers” who can barely cobble together a Python script and want nothing to do with C, C++, or nontrivial JavaScript.

The language distribution still has a few interesting quirks. The repositories marked “Lua,” for example, are all Nmap NSE scripts, such as this one: https://github.com/yunaranyancat/CVE-2025-55182-NSE/blob/main/CVE-2025-55182.nse. Because Nmap already provides mass scanning and reporting capabilities, these scripts can be more practical in real-world operations than generic Python PoCs. This particular NSE script also mirrors behaviors we have seen in our Canary Intelligence data, including the hardcoded multipart boundary `----WebKitFormBoundaryx8jO2oVc6SWP3Sad`, PowerShell and echo-based math checks, and the Assetnote User-Agent. Seeing public PoCs align so closely with attacker behavior is unusual and noteworthy.

Another oddity is a repository marked as “Dockerfile.” It contains a Dockerfile that builds a vulnerable environment and a docker-compose file for running it, which normally wouldn’t qualify it as an exploit. However, the repository also includes a Nuclei template that actively exercises the vulnerable behavior to determine whether the issue is present. Tools like this sit in an odd space: they are not “exploits” in the traditional sense because they do not achieve code execution, but they go beyond simple version checks. We categorize this kind of entry as an “infoleak,” a very small slice of the vulnerabilities we track.

Noteworthy Exploits (and Why They Matter)

Some of the most interesting repositories don’t stand out in any graph but are absolutely worth calling out. One example is a repository published on December 10 that includes logic for loading the Godzilla webshell onto affected systems. Godzilla is a weaponized in-memory webshell widely used by real attackers, and in-memory shells are especially dangerous because they do not touch disk and evade many traditional detection techniques.

A public proof of concept that deploys Godzilla all but guarantees we will see this technique used in the wild. We have seen this pattern before. In our Does Confluence Dream of Shells? research, we documented how CVE-2023-22527 proofs of concept loaded Godzilla-style in-memory shells and influenced real exploit behavior, and the same dynamics are at play here.

The Godzilla loader was not the only interesting in-memory work to appear. In fact, the first in-memory webshell implementation we saw was in the Malyke repository, which documented several Next.js exploit variants and included its own in-memory shell. We published a Go-based variant during our analysis so we could better understand how defenders might attempt to detect the attack.

Another repository, by aiexz, went in a very different direction. Instead of installing a webshell, it deployed a lightweight WAF to block React2Shell payloads entirely. It is an unexpected but clever twist: using the vulnerability to defend against the vulnerability.

There are other interesting repositories that deserve callouts:

1. https://github.com/Legus-Yeung/CVE-2025-55182-exploit/: This one does not attempt RCE at all. Instead, it leaks environment variables, which is a valuable primitive in many real-world attacks.
2. https://github.com/hackersatyamrastogi/react2shell-ultimate/: The “ultimate” scanner. It packs an impressive number of features into 1700 lines of Python, including the “large blob of data” WAF bypass, and even has its own website.
3. https://github.com/pyroxenites/Nextjs_RCE_Exploit_Tool/: A GUI-based tool by a Chinese-language developer, complete with a built-in Unicode-based WAF bypass.

Accessing the Data Yourself

If you want to see the data behind all of this, you can. VulnCheck’s XDB is public and free, and it contains every React2Shell exploit that survived moderation. If you would like to browse the curated set, you can search for CVE-2025-55182:

If you create a free account, our VulnCheck KEV will also show you the associated XDB entries for each CVE. This makes it easy to move from vulnerability information to the curated exploit set. Here is a small snippet from the KEV API for CVE-2025-55182:

"vulncheck_xdb": [
{
    "xdb_id": "b5a20e095cc3",
    "xdb_url": "https://vulncheck.com/xdb/b5a20e095cc3",
    "date_added": "2025-12-04T11:49:55Z",
    "exploit_type": "initial-access",
    "clone_ssh_url": "git@github.com:msanft/CVE-2025-55182.git"
},
{
    "xdb_id": "2caf5e7a5d9b",
    "xdb_url": "https://vulncheck.com/xdb/2caf5e7a5d9b",
    "date_added": "2025-12-04T14:49:43Z",
    "exploit_type": "initial-access",
    "clone_ssh_url": "git@github.com:acheong08/CVE-2025-55182-poc.git"
},
{
    "xdb_id": "b3583e9145ea",
    "xdb_url": "https://vulncheck.com/xdb/b3583e9145ea",
    "date_added": "2025-12-04T17:18:42Z",
    "exploit_type": "infoleak",
    "clone_ssh_url": "git@github.com:klassiker/CVE-2025-55182.git"
},

This brings us to the bigger picture. React2Shell is not just a high-volume CVE, but a reflection of several trends we have been seeing in the public exploit ecosystem.

What React2Shell Teaches Us

React2Shell produced an enormous volume of public exploit repositories. About half of what we reviewed was broken, misleading, or otherwise unusable. Without curation, the meaningful material quickly gets buried by the noise.

Even so, there were genuinely interesting ideas in the mix: in-memory shells, creative payload variations, scanners with real capability, and even defensive uses of the vulnerability. The challenge is simply finding them. That is why we invest so much effort into reviewing public exploits and publishing the approved set. The curated React2Shell dataset is available in XDB for free, if you want to explore it yourself.

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.