A Simulated Attack Story on React Server Components to Exploit React2Shell

Why Should SOC Leaders Care?

If you lead a SOC, you already know the truth: most attacks don’t announce themselves. They start as faint signals buried in noise like an odd payload here, a parsing error there, right until suddenly the dots connect and you realize an attacker was inside your environment long before the SOC had enough context to react. The newly disclosed React2Shell (CVE-2025-55182) vulnerability is exactly that kind of threat: quiet, modern, and incredibly easy to overlook until it’s too late.

This blog is written for SOC leaders, SecOps engineers, and IR practitioners who want to understand not just what React2Shell is, but how it actually looks inside your SOC when someone tries to exploit it. Think of this as a guided tour through a simulated real-world incident: the early weak signals your analysts are likely to miss, the escalation path as the picture becomes clearer, and the unmistakable signs of an RCE attempt unfolding within your own logs and tools.

Why should you care? Because the attack chain we describe mirrors what your SOC will face in the wild. If your SOC is overwhelmed with noise, under pressure to do more with less, or looking for ways to turn every incident into an opportunity for intelligence and automation - this story is for you.

Let’s dive into the attack as the SOC experienced it.

‍Post-Incident Review of a React2Shell Attack

A great SecOps engineer doesn’t just keep the lights on, they turn every incident into an upgrade. In modern SOCs, each alert, anomaly, or confirmed breach is a piece of intelligence that sharpens the entire defensive machine. 

By studying why a true positive succeeded, where the telemetry was strongest, and which subtle signals were overlooked, SecOps engineers transform messy real-world events into cleaner, smarter detections. This is how alert fatigue drops, precision rises, and automations become tailored to the organization’s actual threat patterns, and not theoretical ones. In essence, analyzing SOC events isn’t just post-incident housekeeping, it’s how SecOps forges a continuously improving system that detects faster, responds smarter, and grows stronger with every attack attempt.

Below you can observe a scenario of SOC operation through a case of react2shell exploitation.

Weak Signals

This initial alert reflects an oversized React Server Component (RSC) payload. This is very common during probing activity but rarely malicious on its own. Tier-1 receives it, classifies it as low-fidelity noise, and logs it without escalation. At this stage, no one suspects active exploitation; it’s simply added to the day’s surface traffic anomalies.

Figure 1: WAF alert showing oversized React metadata payload

‍

Now the payload includes markers associated with exploitation: constructor traversals, ‘$@’ references, and serialized gadget chains. Tier-1 flags it as suspicious but still without enough context to escalate. It moves into the “monitor” bucket. This is interesting, but not yet actionable. A Tier-1 note is created for potential follow-up.

Figure 2: WAF alert showing exploit-related keywords inside the RSC payload

‍

Base64-encoded reverse shell patterns are far less ambiguous. Tier-1 recognizes this as possible weaponization. This is the first point where escalation is considered. The analyst notifies the Tier-2 queue, tagging it as “Potential Pre-Exploitation Activity”. Still, without corroborating signals, Tier-2 holds it pending additional evidence.

Figure 3: WAF alert showing embedded base64 reverse-shell content

‍

Next.js fails to parse the payload, throwing internal RSC deserialization errors. Tier-2 now connects this to the earlier WAF anomalies. The pattern starts to make sense: malformed metadata → exploit tokens → base64 shell. Tier-2 opens an investigation ticket but waits for runtime confirmation before declaring an incident.

Figure 4: Application log showing RSC Flight deserialization failure

‍

React Server Components rarely produce abnormal promise-like (then) structures from user input. Tier-2 identifies this as a high-signal behavioral indicator that someone is attempting to trigger code paths deep inside the RSC machinery. At this stage, the event is reclassified as an active exploitation attempt, pending host-level evidence.

Figure 5: RSC telemetry showing abnormal thenable resolution chain.

‍

Active Exploitation Signals

The moment Node spawns a shell, the SOC’s posture shifts instantly. Tier-2 escalates to Tier-3 and the Incident team lead. This confirms the exploit chain succeeded. Automatic containment policies may not trigger yet, but human-led incident response begins. The host is marked “suspected compromised”.

Figure 6: EDR alert showing Node.js spawning a shell via child_process

‍

The reverse shell script in /tmp provides concrete evidence of post-exploitation behavior. Tier-3 forensic specialists begin artifact collection while IR prepares containment options. This validates that the adversary reached code execution and attempted to deploy tooling on the host.

Figure 7: EDR alert showing creation of a suspicious reverse-shell script in /tmp

‍

The reverse shell attempts to connect to an external IP. This is a classic command-and-control (C2) behavior. Network controls luckily block the callout. This event provides both attribution potential and the final proof that the exploit chain was fully executed. IR isolates the instance immediately.

Figure 8: Network alert showing blocked outbound reverse-shell connection attempt

‍

After correlating WAF anomalies, app-layer failures, shell execution, and outbound network attempts, the SIEM automatically produces a high-confidence incident classification: a successful React2Shell RCE attack. Tier-3 now leads incident response, while Tier-1 and Tier-2 shift into monitoring and log collection roles.

Figure 9: SIEM correlation alert showing full React2Shell exploitation sequence

‍

Root Cause Analysis

The root cause analysis of the above-mentioned chain of events indicates of an unsafe deserialization pathway inside React Server Components (RSC), which is a match to the newly discovered CVE-2025-55182 a.k.a react2shell. 

A user-supplied metadata was implicitly trusted and processed without strict structural validation. The RSC Flight protocol allowed attackers to craft malicious object graphs containing manipulated then chains, prototype-traversal sequences, and constructor references. When the server attempted to resolve these objects, it unintentionally invoked JavaScript functions that should never be reachable from external input. This flaw created a direct path from malformed POST requests to arbitrary code execution within the Node.js runtime. Compounding the problem, the application exposed its RSC endpoints publicly, lacked middleware validation of multipart inputs, and did not enforce runtime-level restrictions that could have prevented Node from spawning child processes. 

Ultimately, the vulnerability was not caused by a misconfiguration but by a design-level oversight in how RSC interprets and materializes metadata, enabling attackers to subvert React’s internal execution model and achieve pre-auth RCE.

What is React2Shell (CVE-2025-55182) 

This vulnerability is caused by flow in the RSC handles serialized “Flight” payloads. A lightweight metadata structures that describe server-rendered components. In vulnerable versions, the deserializer accepts attacker-controlled objects without adequate validation, allowing malicious input to influence how the server resolves references, promises, and object constructors. By manipulating fields like status, then, $@, and internal _response structures, attackers can coerce React into invoking dangerous code paths that were never intended to be reachable from user input. Ultimately, this enables remote code execution (RCE) on servers running React 19 or frameworks built on RSC, including Next.js.

‍

Within days of public disclosure, multiple proof-of-concept payloads, automated scanners, and weaponized variants of React2Shell appeared in GitHub repositories, Telegram channels, and exploit marketplaces. 

Early exploitation attempts often involved malformed metadata bursts to test payloads probing how different frameworks handled Flight chunks. Soon after, more polished attack scripts emerged, chaining constructor traversal, ‘_prefix’ injection, and base64-encoded reverse shells into reliable RCE exploits. 

‍

Threat actors began integrating React2Shell into mass-scanning botnets, targeting Next.js servers exposed on port 3000, cloud-hosted demos, and production workloads lacking WAF protections. Although many attempts failed due to version mismatches or partial patches, successful real-world RCE events were observed, including shell spawns, temporary file drops in ‘/tmp’, outbound callback attempts, and early-stage persistence scripts. React2Shell rapidly transitioned from a theoretical vulnerability to an active exploitation vector. 

‍

Below you can observe the actual POC we used for this scenario, taken from a random GitHub repository:

Figure 10: A Proof of Concept that exploits the react2shell vulnerability to run reverse shell

‍

SecOps Lessons Learned

A key lesson for SecOps engineers from this incident is the importance of correlating weak signals early. No single alert in the initial stages was conclusive on its own: oversized RSC metadata, suspicious deserialization tokens, or malformed payload structures. 
But together, they formed a clear pattern of adversarial probing that only became obvious in hindsight. SecOps must improve the ability to stitch these signals across layers: 

• WAF anomalies
• Application parsing errors
• RSC telemetry mismatches 

All these should feed into enrichment pipelines that rank emerging behaviors, not just isolated events. Building automated correlation logic for framework-specific anomalies (like React Server Components metadata deviations) helps turn low-fidelity alerts into meaningful early warnings.

Another critical takeaway is the need to invest in runtime-aware detections and post-exploitation monitoring. The incident only became undeniable once Node spawned a shell, which is far too late in the kill chain. 

SecOps teams can improve visibility by instrumenting deeper behavioral detectors (such as tracking unexpected constructor access, untrusted “thenable” chains, or multipart payloads reaching RSC endpoints). 

Enhancing automated response, like quarantining instances when shell access is detected or blocking outbound C2 attempts, shortens containment time dramatically. 

Ultimately, this event reinforces that SecOps isn’t just about responding to alerts, but it’s about continuously learning from them, refining detections, reducing noise, and hardening the ecosystem against the next iteration of exploitation attempts.

How Mate Security Can Help

Mate security’s core strength lies in transforming a SOC from a reactive, noisy alert-queue into a continuously learning, context-aware defense system. This is a Wisdom-Led Performance model, that builds a living knowledge base, while capturing the existing policies, past incidents, tool configurations, business context, and analyst decisions, and uses it to enrich every new alert with deep context.

With that context built, Mate’s AI agents don’t just raise more alerts: they investigate, correlate, and resolve many of them. Freeing the SOC team from trivial false positives, alert fatigue and enabling analysts to focus on high-fidelity incidents. Simple events auto-resolve with documentation; complex ones escalate with all relevant context pre-gathered. 

Because every resolved case feeds back into the system, the SOC becomes incrementally smarter over time. Threats like subtle deserialization exploits or multi-vector attacks (which previously required painstaking manual correlation) can be detected much quicker and responded to more consistently. For SOC leaders, that means scaling defense quality without linear increases in headcount, reducing burnout, and maintaining institutional knowledge even as personnel change.

‍

How to Prevent React2Shell From Happening to You

The most effective step is to upgrade all React 19 / Next.js installations to patched versions immediately, as the underlying deserialization flaw is a framework-level vulnerability - not something you can fix with minor configuration changes. 

‍

Organizations should also ensure RSC endpoints are never directly exposed to the public internet. Instead, route all traffic through a hardened reverse proxy with strict input filtering, size limits, and WAF signatures enabled for RSC-related anomalies.

‍

At the application layer, enforce strict validation on multipart/form-data input, even if the route normally doesn't expect it. Runtime protections such as eBPF agent, Node.js child-process execution monitors, and container-level syscall restrictions (seccomp/AppArmor) can prevent an exploit from escalating on Linux servers even if the payload is accepted. 

‍

Finally, adopt behavioral detections for unexpected constructor access, untrusted thenable chains, and oversized RSC Flight payloads - early indicators that someone is manipulating React’s internal metadata structures. A layered approach combining patching, routing, input validation, and runtime hardening dramatically reduces the blast radius of React2Shell-style attacks.

‍

How to Check If Your Environment Is Impacted

Identifying whether your organization is using React Server Components (RSC) through React 18/19 or frameworks like Next.js. Any server that processes Flight payloads is potentially vulnerable. 

Analyze dependencies and confirm the version of react-server-dom-webpack in use; versions around 19.0.0 are known to be affected. Next, audit whether your RSC routes (including /_rsc and framework-specific variants) are publicly reachable, even unintentionally. If port 3000 or internal Next.js servers are exposed without a reverse proxy, you may be at immediate risk.

Operational logs can offer strong signals of exploitation attempts. Search for unexpected 500 errors, RSC digests failing, payloads containing $@, status:"resolved_model", or constructor strings, or unusual multipart form-data hitting RSC endpoints. 

On the host, look for Node spawning child processes, files appearing in /tmp, in-momory or unconventional paths, or outbound connections made shortly after exceptions in the application logs. If your telemetry shows any combination of these indicators (especially across multiple layers) it’s a sign that your environment may have already been probed or exploited.