React2Shell: Your Frontend Is Now Your Backdoor

It has a name. It has a CVE. It even has a cute portmanteau. And it’s been absolutely shredding unpatched React apps since December.

Meet React2Shell (CVE-2025-55182): an unauthenticated remote code execution vulnerability in React Server Components that lets an attacker get shell access with a single HTTP request. No credentials. No chains. One request, arbitrary code execution, done.

This week it claimed a big-name victim: LexisNexis. The data analytics giant confirmed that hackers breached its AWS infrastructure on February 24th via a vulnerable, unpatched React frontend app. The attackers — a group calling themselves FulcrumSec — walked out with 2.04GB of structured data: 3.9 million database records, 53 AWS Secrets Manager secrets in plaintext, a complete VPC infrastructure map, and the credentials of over 400,000 users. Including 118 with .gov email addresses. Judges. DOJ attorneys. SEC staff.

LexisNexis says most of the data was “legacy, deprecated” stuff from before 2020. Which is a fun way of saying “yes, we left a loaded gun in an unlocked room for six years.”

What Actually Happened

React2Shell lives in React’s Server Components — specifically in the unsafe deserialization of client-controlled data. When a client submits specially crafted input to a server component endpoint, the deserialization logic can be tricked into executing arbitrary JavaScript server-side. Same logic propagates to Next.js since it uses the same deserialization internals.

The proof-of-concept dropped on December 4th, one day after React disclosed the flaw. Within hours, ShadowServer was detecting 77,664 vulnerable IP addresses. Greynoise watched 181 distinct IPs scanning for it in a 24-hour window. The exploitation pipeline quickly became mechanical:

1. Send fingerprinting request: powershell -c "40138*41979" (predictable result = confirmed vulnerable)
2. Follow up with base64-encoded PowerShell that downloads to memory
3. Disable AMSI, drop a Cobalt Strike beacon
4. Profit (or pivot, or exfiltrate, depending on your threat model)

Step 1 is almost poetic in its simplicity. Multiplication as a vulnerability oracle.

At LexisNexis specifically, the attackers got elevated because the compromised ECS task role had read access to every secret in the account — including the production Redshift master credential. One overprovisioned IAM role, one unpatched container, and suddenly 536 Redshift tables are someone else’s problem.

FulcrumSec contacted LexisNexis for… let’s call it “negotiation.” The company declined. The files hit underground forums shortly after.

The State-Sponsored Angle

It’s not just script kiddies running the multiplication trick. AWS’s own threat intelligence team flagged exploitation within hours of disclosure, attributing it to infrastructure associated with Earth Lamia and Jackpot Panda — Chinese state-linked APT groups. Palo Alto Networks identified UNC5174, another China-nexus actor, among the 30+ organizations already compromised.

So your unpatched Next.js app isn’t just being targeted by bored teenagers. It’s being scanned by nation-state operators doing recon. The standard playbook: whoami, id, write a file, read /etc/passwd, move on. At scale. Against 77,000 exposed addresses.

The Frontend-as-Attack-Surface Problem

Here’s the thing that makes React2Shell more philosophically interesting than your average RCE: it’s a frontend framework that introduced server-side code execution as a feature, and then shipped a deserialization bug in that feature.

Server Components were sold as “write server-side logic with React ergonomics.” Which sounds nice until you realize you’ve now merged two historically separate attack surfaces — the frontend (XSS, CSRF, UI tricks) and the backend (RCE, SQLi, auth bypasses) — into one codebase that your frontend team owns and your security team hasn’t fully threat-modeled yet.

The fix requires updating React, rebuilding, and redeploying. That “rebuild” step is load-bearing — which is why weeks after disclosure, 77k IPs are still sitting exposed. Patching a library in package.json isn’t enough. You have to ship new artifacts. Every team with a quarterly release cadence is currently sweating.

Lessons, Scored for Maximum Embarrassment

LexisNexis: You had an unpatched React app with an ECS role that could read every secret in your AWS account. That’s not one failure, that’s a stacked combo of “we didn’t patch” AND “we didn’t do least-privilege IAM.” Both. At the same time. For a company whose entire product is knowing things about people.

React/Vercel ecosystem: You shipped server-side execution in a framework historically used for pure UI, and the deserialization bug took a minute to find. It was found. Ship security advisories faster next time.

Everyone with a Next.js app: Go check your deployment. Right now. Not after the standup. Open a new tab and check.

The vulnerability is patched in current React releases. The rebuild-and-redeploy requirement is annoying. It is significantly less annoying than 53 plaintext secrets and a visit from Jackpot Panda.

---

Sources: BleepingComputer — LexisNexis breach · BleepingComputer — React2Shell exploitation