Three New React Vulnerabilities Surface on the Heels of React2Shell

December 12, 2025
By Sonatype Research Team

6 minute read time

CVE-2025-55183, CVE-2025-55184, and CVE-2025-67779 require immediate attention

On December 3, the React team disclosed React2Shell — a set of two critical bugs in React Server Components (tracked as CVE-2025-55182 and CVE-2025-66478) that together enable Remote Code Execution (RCE) through a deserialized HTTP request.

It's classic "worst case" material:

• Unsafe deserialization of attacker-controlled data.
• No authentication required.
• Single HTTP request to full RCE on the server.
• Deeply embedded in modern frameworks like Next.js.

Within hours, Cloudflare was already seeing scanning and attempted exploitation in the wild, including traffic tied to Asia-linked threat actor infrastructure. Since then, three more RSC vulnerabilities have been disclosed that live in the same neighborhood as React2Shell: CVE-2025-55183, CVE-2025-55184 and CVE-2025-67779.

Think of these as a family of RSC issues, not separate, one-and-done events.

What's New Beyond React2Shell?

React2Shell (-55182 + -66478) is the RCE everyone is rightly worried about. The new issues widen the impact. Importantly, two new CVEs are not related to React2Shell at all. We should expect to continue to see heavy scrutiny on packages with Critical flaws, which typically results in additional vulnerabilities disclosed.

CVE-2025-55183 – Server-side Source Code Exposure

Under specific conditions, an attacker can coerce RSC Server Functions into returning a specifically-defined "Server Function" instead of just data.

If that source includes:

• Hard-coded keys or tokens.
• Internal endpoints.
• Proprietary logic.

…then a "medium" CVSS bug becomes a very practical way to leak secrets and map your application internals.

CVE-2025-55184 and CVE-2025-67779 – Pre-auth Denial-of-Service

By sending an RSC Flight payload with cyclic Promise references, an attacker can push the server into unbounded recursion / event-loop lockup and effectively take it offline — no credentials, no user interaction.

That's a clean pre-auth DoS against any Internet-facing RSC deployment. CVE-2025-67779 was released as a follow-on to -55184 due to the initial fixed version failing to address the full problem.

These issues don't replace React2Shell; they stack on top of it. While one bug gives you RCE, the others give you ways to knock over servers and leak code, all in the same RSC machinery.

Exploitation Isn't Theoretical

Several research organizations have shown this is already being worked at scale: in the first days after disclosure, Cloudflare's WAF saw hundreds of millions of React2Shell-related hits and thousands of unique IPs and User-Agent strings probing for exposure.

A few takeaways from that:

• React2Shell was integrated into scanning workflows immediately.
• Attackers aren't just poking randomly; they're fingerprinting React/Next.js stacks and prioritizing targets.
• As more RSC vulnerabilities are disclosed, it's reasonable to assume they'll be added to the same pipelines.

These vulnerabilities should be a cause for concern — by nature, these vulnerabilities are very difficult for an attacker to discover. But, once they are discovered, they are incredibly easy to exploit. Essentially, any unpatched system on the public web is exploitable, and with attackers relying more and more on automation to find and attack those systems, their owners should assume they will be attacked.

What You Should Do Now

Treat all the RSC CVEs as one incident: CVE-2025-55182 (RCE) + 55183 (source leak) + 55184 (DoS) [+ 67779 patch follow-up].

1. Upgrade to the Current Fixed Versions

Follow the React team's updated guidance, which now explicitly includes the DoS and source-exposure issues as well as a follow-up case, CVE-2025-67779. If your framework supports RSC, assume you're affected even if you don't think you "use" server functions.

2. Inventory Where React RSC Actually Lives

You can't patch what you don't know you have.

• Identify all services (not just front-end apps) that depend on React 19 and RSC-capable frameworks.
• Pay special attention to internal admin apps, embedded React frontends in appliances / dashboards, and "sidecar" UIs running on the edge or within VPNs.

This is where decent dependency visibility and SBOM/SCA tooling really pays off — especially as more RSC variants show up over time.

3. Harden the Edge While You Patch

You shouldn't rely on a WAF as your only control, but it's an important pressure valve while you roll out fixes.

• Enable and tune WAF rules that specifically target the React2Shell payloads (CVE-2025-55182) and the two new RSC vulnerabilities (CVE-2025-55183, 55184).
• Monitor for large or unusual RSC payloads, spikes in 5xx / timeouts on RSC endpoints, and any responses that look suspiciously like server-side source.

4. Assume Probing and Hunt Accordingly

If you were slow to apply the initial React2Shell patches, plan as if somebody at least tried to hit you. Look for:

• Repeated requests with RSC-specific payloads or scanners (Nuclei templates, "React2ShellScanner" UA, etc.).
• Error spikes or CPU saturation on services running vulnerable versions.
• Logs or caches where server source code might have been inadvertently recorded.

If you find evidence of source leakage through 55183, treat any exposed secrets as compromised and rotate them.

Bigger Picture: Vulnerability Families, Not Single Bugs

The real lesson here isn't just "patch React2Shell quickly" — it's that:

• RSC is a complex, high-power feature; when something goes wrong in its serialization and execution path, you're likely to get RCE, DoS, and info leaks out of the same design.
• Once a high-profile bug lands in a core framework, you should expect follow-on CVEs in the same area as researchers and attackers both dig deeper.

So the mindset shift is:

• Don't treat React2Shell, 55183, 55184, and 67779 as four surprises.
• Treat them as four early members of a React RSC vulnerability family you'll be living with for a while.

If you design your processes around that — good dependency visibility, reliable upgrade paths, and realistic incident response — you're much better positioned for whatever the next RSC variant looks like.