ZeroDay Field Notes - React2Shell: From Theory to Practice in 72 Hours

UncleSp1d3r here. Last week we flagged CVE-2025-55182 as a critical pre-auth RCE in React Server Components with a perfect 10.0 CVSS and public PoCs floating around. This week? Confirmation that China-nexus threat actors have been weaponizing it in the wild, dropping miners, bots, Cobalt Strike, and Sliver across exposed Next.js instances. The patch-to-exploitation window was measured in hours, not days, and the tooling is mature enough that even low-skill operators are taking shots.

If you're running React Server Components in production and haven't patched, you're already playing catch-up. Let's talk about what's actually happening out there and what you need to do about it.

React2Shell: The Exploitation Picture Clears Up

The React team's emergency advisory dropped on December 3rd with fixes in React 19.0.1, 19.1.2, and 19.2.1. By December 10th, Trend Micro published detailed analysis of active in-the-wild exploitation with concrete IOCs and post-exploitation payloads.

Here's what we know about the exploitation chain. The vulnerability lives in the Flight protocol deserialization logic used by React Server Components to handle Server Actions. An attacker sends a crafted multipart HTTP request with a Next-Action header containing malicious Flight protocol data. The payload abuses JavaScript prototype pollution via $@/$B references and resolved_model manipulation to achieve arbitrary code execution in the Node.js server process.

The real-world campaigns documented by AWS and others show attackers deploying:

• XMRig and other cryptocurrency miners
• Botnet agents (including variants of Mirai and Gafgyt)
• Cobalt Strike and Sliver beacons for hands-on access
• Nezha monitoring agents (legitimate open-source tool abused for persistence)
• Cloudflare tunnel reverse proxies for exfiltration and pivoting

The exploitation requires the target to be running Next.js with the App Router and specific middleware configurations, which limits the attack surface somewhat. But when conditions align, you're looking at full server compromise with no authentication required.

PoC Analysis and Detection

A functional PoC surfaced on GitHub demonstrating the complete exploitation chain. The key technical primitives:

1. Craft a multipart request with Next-Action header
2. Include Flight protocol data with $@/$B references to trigger deserialization
3. Use resolved_model and constructor:constructor chains to achieve RCE
4. Bypass basic WAF filters (naive __proto__ blocking doesn't work)

For defenders, Trend Micro, AWS, and others have published detection rules targeting:

• HTTP requests with Next-Action header + suspicious Flight protocol patterns
• Processes spawned by Node.js with child_process.exec/execSync/spawn
• Network connections from Node.js to known malicious infrastructure
• File system artifacts like dropped miners or tunnel configs

The immediate action is straightforward: patch React and Next.js to fixed versions. If you can't patch immediately, WAF signatures from Cloudflare, Fastly, and others can provide temporary mitigation, but these should be considered stopgaps, not solutions.

CISA added this to the Known Exploited Vulnerabilities catalog on December 6th, which means federal agencies have hard deadlines. The rest of us should treat it with the same urgency.

Gladinet: Still Exploited, Still a Problem

We flagged CVE-2025-11371 in Gladinet CentreStack and Triofox back in October when Huntress first disclosed the unauthenticated LFI to ViewState deserialization chain. This week, Huntress published a follow-up confirming active exploitation with specific indicators.

The attack chain remains the same: exploit the /storage/filesvr.dn endpoint to read arbitrary files (specifically web.config), extract the ASP.NET machineKey, and use it to craft a malicious ViewState payload that deserializes into remote code execution as SYSTEM. What's new is the confirmation that attackers are actively scanning for and exploiting vulnerable instances.

Huntress observed exploitation attempts using tickets containing the static token prefix vghpI7EToZUDIZDdprSubL3mTZ2, which can be used as a detection signature. They also documented connections from the malicious IP 147.124.216.205 and provided updated hunting guidance for defenders.

The vendor released patches in version 16.12.10420.56791 back in November, and CISA added this to KEV on November 4th. If you're still running an unpatched instance, especially one exposed to the internet, assume compromise and rotate all credentials stored in web.config after patching.

Malware Tradecraft: Three Families Worth Studying

ValleyRAT: Kernel Rootkits and Builder Secrets

Check Point Research dropped a comprehensive teardown of ValleyRAT, a sophisticated multi-stage malware family that's been making the rounds in targeted campaigns. The analysis is operator gold--it covers everything from the builder toolchain to the kernel-level rootkit components.

ValleyRAT's delivery mechanism uses DLL side-loading via legitimate signed binaries. Once loaded, it deploys a modular payload that can include:

• Kernel-mode rootkit drivers for process/file/registry hiding
• Keylogging and clipboard monitoring
• Browser credential theft (Chrome, Edge, Firefox)
• File exfiltration from user directories
• Anti-analysis checks (VM detection, debugger presence)

The interesting part is the builder infrastructure. Check Point reverse-engineered the obfuscation techniques used by the builder, which employs polymorphic code generation, API hashing with custom seeds, and encrypted configuration blocks. Each generated sample is unique, making signature-based detection challenging.

For red teams, the DLL side-loading chains and rootkit persistence mechanisms are worth emulating. For defenders, focus on behavioral detection: unsigned kernel drivers, DLL loads from unexpected paths, and anomalous registry/file system hiding behavior.

GhostPenguin: Custom UDP C2 with RC5 Encryption

Trend Micro's threat hunters documented GhostPenguin, a previously unknown Linux x86_64 backdoor with some creative C2 architecture. The malware was discovered via AI-assisted threat hunting (analyzing millions of samples to find outliers), which is an interesting meta-story about how detection is evolving.

GhostPenguin implements a custom UDP-based protocol running over DNS port 53 to blend with legitimate traffic. The protocol features:

• RC5 encryption for all C2 communications
• Custom reliability layer (ACKs, retries, sequence numbers)
• Heartbeat mechanism to maintain connectivity
• Approximately 40 commands for file operations and remote shell access

The use of UDP 53 is clever--most networks allow outbound DNS, and the protocol's custom reliability layer means it doesn't need TCP's guarantees. The RC5 encryption is an unusual choice (most modern malware uses AES or ChaCha20), but it's perfectly functional for this use case.

Trend Micro provides a SHA256 hash and C2 IOCs for hunting. For defenders, monitor outbound UDP 53 to non-DNS infrastructure and look for the specific packet patterns documented in the analysis. For offense, this demonstrates effective protocol design for constrained environments where TCP might be blocked or monitored.

The malware managed to stay undetected on VirusTotal for months after initial submission (2025-07-07), which speaks to its evasion capabilities. Treat it as a reference implementation for custom C2 protocols.

AutoIT3: Old Tool, New Tricks

Xavier Mertens at SANS ISC detailed a campaign using compiled AutoIt3 scripts to drop and execute shellcode in a way that avoids common detection patterns. The technique is worth breaking down because it's deceptively simple but effective.

The compiled AutoIt binary uses FileInstall() to embed dropper artifacts (deobfuscated versions of files named things like inhumation, buncal, tmp371u7sfd) in the binary at compile time. At runtime, these files are extracted to %TEMP%, then the script:

1. Reads the dropped file (which contains ASCII-shifted shellcode)
2. Deobfuscates it (simple character offset manipulation)
3. Allocates RWX memory via DllCall("kernel32.dll", "ptr", "VirtualAlloc", ...)
4. Writes the shellcode into memory
5. Executes via DllCall("user32.dll", "int", "CallWindowProc", ...)

The use of CallWindowProc instead of the more common CreateThread or NtCreateThreadEx is the interesting bit. It's an indirect execution technique that can bypass thread-creation telemetry that many EDRs rely on.

The observed payloads were Quasar RAT and Phantom stealer, both commodity malware. But the delivery technique is portable and demonstrates effective evasion through legitimate scripting languages.

For red teams, AutoIt is an underutilized delivery mechanism--it's a legitimate scripting language with compiled binary support, meaning you can package your payload in a way that looks like legitimate automation. The FileInstall + VirtualAlloc + CallWindowProc chain is clean and doesn't require touching disk with your final payload.

Hunt for AutoIt binaries executing DllCall with memory allocation/execution functions, monitor for the specific temp file patterns documented in the SANS diary, and review the provided SHA256 hashes.

Tooling Corner: OGhidra Bridges LLMs and Reverse Engineering

For those of us who spend time in Ghidra, OGhidra is worth checking out. It's an integration layer that connects Ghidra to local LLMs via Ollama, enabling AI-assisted binary analysis through natural language queries.

The workflow is simple: install the Ghidra script, point it at your local Ollama instance, and start asking questions about the binary you're analyzing. "What does this function do?" "Find all calls to recv()" "Explain this obfuscation pattern." The LLM generates responses based on the disassembly context.

There's also a companion project, GhidraMCP, that implements the Model Context Protocol for more sophisticated integrations with tools like OpenWebUI. A workshop at Countermeasure 2025 walks through building a complete local LLM stack for reverse engineering.

The practical value is mixed--LLMs are great for explaining complex code and automating repetitive analysis tasks, but they hallucinate and shouldn't be trusted blindly. Still, for speeding up initial reconnaissance or understanding unfamiliar architectures, it's a useful addition to the toolkit.

For operators, the interesting angle is the underlying technique: augmenting static analysis tools with dynamic AI assistance. The same approach could be applied to other RE tools (IDA, Binary Ninja, etc.) and extended to offensive use cases like automated vulnerability discovery or exploit generation.

Closing Thoughts

This week was a study in velocity. React2Shell went from disclosure to weaponization faster than most organizations can schedule an emergency change window. Gladinet continues to be exploited months after patches shipped. And the malware families we're tracking show increasing sophistication in evasion and persistence.

The operators who win are the ones who can move fast--patching before exploitation, detecting before exfiltration, and hunting before persistence. Speed matters more than perfection. An imperfect patch deployed today beats a perfect patch stuck in change management next week.

So patch your React apps, audit your edge appliances, and maybe spend some time with that Ghidra integration. The research is good, the tradecraft is evolving, and there's always another shell waiting to be popped.

Do the work. Don't wait for permission.

-- UncleSp1d3r