Metro4Shell: React Native Dev Server Flaw Exploited in the Wild to Hijack Developer Machines

On Windows, that shell invocation translates to cmd /c start "" /b <url> — and because the url value is never validated, escaped, or restricted to safe protocols, an attacker can inject arbitrary commands into that shell call. On macOS and Linux, the open or xdg-open utilities are invoked, which limits the attack surface but still allows abuse via crafted URI schemes.

The vulnerability was assigned CVE-2025-11953 and published on November 3, 2025. JFrog, which reserved the CVE, rated it 9.8 Critical. The React Native Community released a fix in version 20.0.0 of the CLI packages. But as VulnCheck's threat-intelligence team documented, exploitation in the wild began just weeks after the public disclosure — and it has not stopped.

Understanding the Vulnerability

At its core, CVE-2025-11953 is a textbook OS command injection (CWE-78) amplified by an insecure default network configuration. Let's walk through exactly how it works.

The Vulnerable Code Path

When a React Native developer starts the Metro bundler, the CLI launches an HTTP server. Among its routes is an endpoint called /open-url, handled by the openURLMiddleware function. In vulnerable versions, the middleware does something like this:

The open NPM package is designed to open a URL in the user's default browser. Under the hood, it constructs an OS-specific command:

• Windows: cmd /c start "" /b <url>
• macOS: open <url>
• Linux: xdg-open <url>

Because the url value is concatenated directly into the command string on Windows, an attacker can break out of the intended context and execute arbitrary commands.

The Exploit: One POST Request

The proof-of-concept published by JFrog demonstrates the attack in its simplest form:

When this request hits the Metro server, the open package dutifully passes the string to the Windows shell. The shell interprets it as a command and launches calc.exe. Replace calc.exe with powershell -EncodedCommand <base64_payload> and you have a full remote code execution chain.

The Default Bind Problem

The exploit only works remotely because of the second flaw: the Metro server's default bind address. When no --host flag is specified, the server starts with an undefined host argument, which causes Node.js to listen on 0.0.0.0 (all interfaces) and :: (all IPv6 interfaces). This means the development server — a tool intended for local use — is silently accessible from the entire local network, and potentially from the internet if the machine has a public IP or is behind a misconfigured router.

The Full Attack Chain

1. Reconnaissance: The attacker scans the network (or the internet) for hosts listening on TCP port 8081 — the Metro server's default port.
2. Exploitation: The attacker sends a crafted HTTP POST request to http://<target>:8081/open-url with a malicious url value in the JSON body.
3. Command Execution: The Metro server's openURLMiddleware passes the string to the open package, which spawns a child process via the OS shell.
4. Payload Delivery: On Windows, the attacker-controlled string is interpreted as a shell command. The attacker can launch PowerShell, download additional malware, disable security tools, and establish persistence — all running with the privileges of the developer who started the Metro server.

The Fix

The vendor patch, contained in commit 15089907d1f1301b22c72d7f68846a2ef20df547 (https://github.com/react-native-community/cli/commit/15089907d1f1301b22c72d7f68846a2ef20df547) and shipped in version 20.0.0, adds strict protocol validation to the /open-url endpoint. Only URLs with http:// or https:// schemes are now accepted; all other values are rejected before they reach the open package.

Who Is Affected

React Native is one of the most widely used cross-platform mobile development frameworks in the world. According to the 2025 Stack Overflow Developer Survey, it remains among the top five most popular frameworks for mobile development. The @react-native-community/cli package is the default command-line interface for React Native projects, and the Metro bundler it ships with is the standard development server for the ecosystem.

Any developer or CI/CD pipeline running a React Native project with the Metro server started on a network-accessible interface — which is the default behavior — is potentially exposed. This includes individual developers on corporate Wi-Fi networks, shared development servers, and automated build environments where the Metro server is launched as part of testing workflows.

Notably, projects using Expo's managed workflow are not affected, as Expo does not rely on the vulnerable Metro implementation from @react-native-community/cli-server-api.

Real-World Risk

Active Exploitation Confirmed

This is not a theoretical risk. VulnCheck's threat-intelligence team documented active exploitation (https://www.vulncheck.com/blog/metro4shell_eitw) beginning on December 21, 2025, approximately six weeks after the public disclosure and patch release. The researchers observed multiple distinct attack waves:

• December 21, 2025 — First confirmed in-the-wild exploitation
• January 4, 2026 — Second wave of attacks
• January 21, 2026 — Third wave of attacks

The attacks, informally dubbed "Metro4Shell" by researchers, follow a consistent pattern: attackers send a POST request to /open-url containing a Base64-encoded PowerShell payload. The payload performs the following steps:

1. Adds Microsoft Defender exclusion paths via Add-MpPreference -ExclusionPath to evade endpoint detection.
2. Opens a TCP connection to an attacker-controlled command-and-control (C2) server.
3. Downloads a packed Rust binary to the %TEMP% directory.
4. Executes the binary with a large argument list.

VulnCheck identified the following C2 infrastructure IP addresses associated with the campaign:

• 65.109.182.231
• 223.6.249.141
• 134.209.69.155
• 8.218.43.248
• 47.86.33.195

The payloads connect to these hosts on non-standard ports such as 60124 and 60130.

File hashes for the malicious binaries observed in the wild:

• Packed binary (SHA-256): d8337df3aff749250557bf11daf069eb404cce0e6f4f91c6bd3f78aed6e9d6
• Unpacked binary (SHA-256): 7ecbb0cc88dfa5f187c209a28bd25e8e2d5113bb898a91ae273bca5983130886

CISA KEV Designation

On February 5, 2026, CISA added CVE-2025-11953 to its Known Exploited Vulnerabilities (KEV) catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2025-11953), confirming active exploitation and classifying the vulnerability as:

• Exploitation: Active
• Automatable: Yes
• Technical Impact: Total

For U.S. federal agencies, inclusion in the KEV catalog triggers mandatory remediation timelines under Binding Operational Directive 22-01. For everyone else, it should serve as a clear signal that this vulnerability demands immediate attention.

What Attackers Can Do

Successful exploitation gives an attacker arbitrary command execution with the privileges of the developer running the Metro server. In practice, this means:

• Source code theft: Access to all repositories cloned on the developer's machine.
• Credential harvesting: API keys, tokens, SSH private keys, environment variables, and cloud credentials stored locally.
• Supply-chain compromise: Injection of malicious code into the project's source tree, which could propagate to production builds.
• Lateral movement: Use the compromised developer machine as a pivot point to access internal networks, CI/CD pipelines, and cloud environments.
• Ransomware deployment: Encrypt the developer's files or use their access to target broader organizational infrastructure.
• Persistence: Install backdoors that survive reboots and continue providing access long after the initial exploitation.

What You Should Do

1. Upgrade Immediately

The single most important action is to upgrade @react-native-community/cli-server-api and @react-native-community/cli to version 20.0.0 or later.

Verify the installed version across all developer workstations and CI/CD agents:

Any version below 20.0.0 is vulnerable.

2. Bind Metro to Localhost (If Upgrade Is Not Immediately Possible)

If you cannot upgrade right away, force the Metro server to listen only on 127.0.0.1:

This eliminates the remote attack vector entirely. The trade-off is that you will not be able to access the dev server from other devices on your network (such as physical test phones). For those scenarios, use USB port forwarding via adb reverse for Android or a secure tunnel.

3. Apply Firewall Rules

Block inbound traffic to the Metro development server port (default 8081) at both the host-based firewall and the network perimeter:

• Windows: netsh advfirewall firewall add rule name="Block Metro" dir=in action=block protocol=TCP localport=8081
• macOS: Use the built-in application firewall or pfctl rules.
• Linux: sudo ufw deny in 8081/tcp

4. Deploy Detection Rules

Monitor for exploitation attempts using the following indicators:

Network-based detection:

• HTTP POST requests to /open-url on port 8081 from non-local IP addresses.
• Outbound connections from developer workstations to the known C2 IPs: 65.109.182.231, 223.6.249.141, 134.209.69.155, 8.218.43.248, 47.86.33.195 on ports 60124 and 60130.

Host-based detection:

• Windows Event ID 4688 (Process Creation) where cmd.exe or powershell.exe is spawned by a parent process of node.exe with command-line arguments containing start "" /b or -EncodedCommand.
• Creation of new Microsoft Defender exclusion paths via Add-MpPreference.
• Files matching the known malicious hashes appearing in %TEMP%.

Log indicators:

• Metro server access logs showing POST /open-url requests, especially from external IP addresses.
• Node.js process logs containing open(url) calls with non-HTTP/HTTPS URLs.

5. Audit Your Environment

• Run netstat -tlnp | grep 8081 (Linux/macOS) or netstat -ano | findstr 8081 (Windows) on all developer machines to identify exposed Metro servers.
• Review CI/CD pipeline configurations for any steps that launch the Metro server on a shared or networked host.
• Check package-lock.json and yarn.lock files across all projects for vulnerable versions of @react-native-community/cli-server-api.

6. Consider Alternative Tooling

If your project's architecture permits it, consider switching to the Expo managed workflow, which does not use the vulnerable Metro implementation from @react-native-community/cli-server-api. This eliminates the attack surface entirely, though it may require changes to your project structure and development workflow.

The Bigger Picture

CVE-2025-11953 is a stark reminder that development tools are part of the attack surface — and they are often the least hardened part. Developers tend to think of their local dev servers as ephemeral, harmless utilities. But when those servers bind to all network interfaces by default and expose endpoints that pipe user input directly into shell commands, they become high-value targets.

The root cause here is a pattern that security researchers have warned about for years: unsanitized input flowing into command-execution sinks. The open NPM package was never designed to handle adversarial input. It is a convenience library meant to open URLs in a browser. Using it as the backend for a network-exposed HTTP endpoint without any input validation is a recipe for exactly the kind of catastrophe we are seeing now.

The secondary issue — binding to 0.0.0.0 by default — is equally instructive. The principle of least privilege should extend to network interfaces. A development server that is only needed locally should only listen locally. The React Native community has acknowledged this, and version 20.0.0 addresses both the input validation gap and the network exposure.

Perhaps the most concerning aspect of this vulnerability is the supply-chain implications. Developer workstations are treasure troves of credentials, source code, and pipeline access. Compromising a single developer's machine can give an attacker the ability to inject malicious code into production builds — potentially affecting millions of end users who install or update the resulting mobile applications. The observed attack payloads, which include Defender evasion and custom compiled binaries, suggest that the threat actors behind Metro4Shell understand this and are building toward exactly that kind of supply-chain compromise.

As Szymon Rybczak, a React Native community contributor, noted on X (https://x.com/SzymonRybczak/status/1986199665000566848), the community moved quickly to address the issue once it was reported. But with active exploitation confirmed across multiple waves and CISA now mandating remediation for federal agencies, the window for complacency has closed. If you run React Native projects, check your versions today.