Vulnerability Intelligence Brief: CVE-2025-11953 - Your React Native Dev Server Is an Open Door

CVSS 9.8 | @react-native-community/cli-server-api | Exploit: Yes – PoC public, active in-the-wild, CISA KEV

Introduction

Vulnerability Intelligence Brief is a recurring analysis series focused on a single CVE at a time. Rather than restating severity scores or vendor summaries, each brief examines exploitability in context, signal timing, and operational remediation implications. The goal is to understand how a vulnerability behaves in real environments and what that means for remediation decisions.

TL;DR

• Featured CVE: CVE-2025-11953 – OS command injection in the React Native Metro development server, exploitable by unauthenticated remote attackers with no user interaction required
• Risk Level: Critical (CVSS 9.8, scored by JFrog as CNA;  NVD still awaiting analysis)
• Key Insight: Active exploitation began 46 days before KEV listing, while EPSS remained below 0.6%. List-driven prioritization would have missed this window.
• Action Required: Update @react-native-community/cli-server-api to v20.0.0 or higher. If you can't patch now, bind Metro to localhost: npx react-native start --host 127.0.0.1

What's Actually Happening Here

The Metro Development Server, started automatically when you run npx react-native start, binds to all network interfaces (0.0.0.0) by default, not localhost. It exposes an HTTP endpoint /open-url designed to help developers open files in their editor during debugging. These endpoints accept POST requests with user-supplied parameters and pass them to the open() function without sanitizing input first. 

An unauthenticated attacker on the same network can send a crafted POST request to execute arbitrary OS commands on the developer's machine. On Windows this results in arbitrary OS command execution with parameter control. On macOS and Linux the scope is limited to executing existing binaries with no parameter control.

Averlon’s analysis breaks down attack prerequisites, exploitability, and real-world exposure on the full CVE page.

Why This Matters Beyond the Score

This targets developer machines, not production servers. A compromised developer workstation gives attackers access to source code, credentials, cloud provider tokens, and the ability to inject malicious code into builds before they ship. Averlon's impact analysis flags the supply chain risk explicitly: an attacker can modify project source code to inject backdoors. Active campaigns have been deploying multi-stage Rust-based malware with Microsoft Defender evasion, persistence, and C2 capabilities. This reflects targeted post-exploitation activity rather than opportunistic scanning.

The Attack Reality

Complexity: Low – send a crafted POST to port 8081, get code execution. No authentication, no user interaction required. Note that Red Hat scored this 8.1 (High, AC:High), arguing high complexity because the vulnerability is "not applicable to a specific Red Hat product." Red Hat’s 8.1 score reflects product applicability constraints, not the inherent exploit mechanics. From a technical standpoint, sending a crafted POST to port 8081 requires no authentication and no user interaction. Averlon's analysis agrees with GHSA and NVD on AC:Low. The actual exploit is straightforward.

Prerequisites:

• Running a vulnerable version of @react-native-community/cli (v4.8.0 through 20.0.0-alpha.2)
• Metro Development Server is running (standard part of any React Native dev workflow)
• Attacker has network access: same local network (office Wi-Fi, co-working space)
• No authentication, no user interaction required

Is this being actively exploited?

Yes. CISA added CVE-2025-11953 to the Known Exploited Vulnerabilities (KEV) catalog on February 5, 2026. A KEV listing means CISA has confirmed active exploitation against real targets, a higher bar than PoC availability alone. Exploitation was first observed December 21, 2025, 46 days before KEV listing. PoC code is publicly available.

Third-Party Reporting on Exploitation

Several third-party security publications have documented in-the-wild exploitation of this vulnerability, reinforcing the operational impact:

• ‍The Hacker News reported threat actors exploiting Metro4Shell (CVE-2025-11953) in attacks that delivered payloads including anti-analysis and persistent behaviors.‍
• SecurityWeek described ongoing in-the-wild exploitation targeting vulnerable instances and noted attacker measures to evade endpoint controls.‍
• BleepingComputer detailed attackers using the flaw to breach systems on both Windows and Linux, delivering advanced payloads after initial exploitation.

These reports align with observed exploitation timelines and reinforce that CVE-2025-11953 has been leveraged operationally against exposed development servers.

What To Do About It

Right Now:

• Update @react-native-community/cli-server-api to v20.0.0 or higher across all React Native projects. The fix adds strict URL validation that blocks the injection path.

If You Can't Patch Immediately:

• Bind Metro explicitly to localhost: npx react-native start --host 127.0.0.1. Removes network reachability entirely and eliminates the attack surface without requiring an upgrade. Note: this will break testing on physical devices connected over Wi-Fi. If you rely on wireless device testing, switch to USB or use an emulator while the workaround is in place.

Detection Angle:

• Look for unexpected POST requests to port 8081 from non-localhost addresses, particularly to /open-url
• Monitor for unusual child processes spawned from Node.js/Metro processes on developer machines
• On Windows: PowerShell encoded commands and Microsoft Defender exclusion additions are indicators of post-exploitation activity observed in active campaigns

Remediation Pathway:

• Run npm ls @react-native-community/cli-server-api in each React Native project to identify affected versions
• Update and verify Metro starts cleanly post-upgrade
• Add --host 127.0.0.1 to dev scripts as a permanent defense-in-depth measure even after patching

The Bigger Picture: Development tooling is often under-secured relative to production infrastructure, but it sits upstream of everything. Dev servers, build tools, and local CLIs are high-value targets precisely because security controls often tend to stop at the production perimeter. When the tool that builds your app is compromised, the app is compromised.

What We're Watching

• The gap between active exploitation and defensive signals is wider than most teams assume. CVE-2025-11953 is a clean case study. Exploitation began December 21. EPSS, the standard probabilistic scoring system used by many vulnerability management programs to prioritize remediation, sat at 0.49% the day after first confirmed attacks. It stayed below 0.6% for the entire six weeks that followed, through Christmas, through January, as attackers continued deploying malware on developer machines. 

CISA added it to KEV on February 5, and EPSS spiked from 0.4% to 15.6% overnight. Not because exploitation increased, but because the label arrived. This is a structural characteristic of list-based defense: the signals update after exploitation is confirmed, which means by definition you are reacting to something that is already happening. For CVE-2025-11953, that lag was 46 days.

NVD still hasn't scored this CVE. As of today the NVD entry for CVE-2025-11953 shows "Awaiting Analysis." The 9.8 score comes from JFrog as the CNA. NVD's scoring backlog has been a known problem, but it matters here because many downstream tools, dashboards, and vulnerability management workflows pull from NVD as their authoritative source. These two gaps compound each other. A CVE can be actively exploited, KEV-listed, and still show low EPSS and no NVD score simultaneously, creating a window where scoring-based triage has incomplete data to work with.

Vulnerability Intelligence Insight of the Week

Here is the EPSS score trajectory for CVE-2025-11953, pulled directly from FIRST.org's daily data feed:

For teams gating remediation on EPSS percentiles alone, this vulnerability would likely not have triggered urgency until after KEV listing. The model didn't detect the exploitation. It detected the label. For 46 days, EPSS scored this vulnerability below the 70th percentile while attackers were actively deploying malware on developer machines. The score then jumped 38x in 24 hours, not because the threat changed, but because CISA published a list entry.

This isn't a criticism of EPSS. It's doing what it's designed to do. The point is structural: any defense posture that depends on lists, scores, and catalogs to trigger action is, by design, reactive. Those signals confirm exploitation after the fact. By the time they update, you are likely already behind.

The right question isn't "is this on a list?" It's "does this vulnerability exist in my environment, and what does an attacker's path look like from there?" That requires understanding exploitability in context: what's reachable, what's exposed, what the blast radius looks like in your specific environment. That's the gap remediation operations is designed to close.

Further References

Deep Dive: CVE-2025-11953 on Averlon Vulnerability Intelligence

Full VI Platform: research.averlon.ai/vulnerability-intelligence