Yes. CISA added CVE-2025-11953 to its Known Exploited Vulnerabilities catalogue on 5 February 2026, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. React Native Community CLI contains an OS command injection vulnerability which could allow unauthenticated network attackers to send POST requests to the Metro Development Server and run arbitrary executables via a vulnerable endpoint exposed by the server.
What the exploitation evidence means for this CVE
CISA’s KEV listing is the key signal here because it reflects confirmed exploitation, not just theoretical risk. For practitioners, the practical question is whether the vulnerable React Native Community CLI endpoint is reachable in your environment, whether the Metro Development Server is exposed beyond intended developers, and whether any systems still present the vulnerable command-injection path.
For a case like this, “exploited in the wild” should change priority immediately: exposure review, containment, and patch or mitigation become urgent tasks rather than routine backlog items. The decision point is not whether the vulnerability is interesting, but whether any reachable instance can accept the POST requests that trigger command execution.
How to confirm whether you are exposed
Start by identifying where React Native Community CLI is installed and whether the Metro Development Server is present in development, test, CI, or shared build environments. Command-injection issues often survive because teams know the tool is used somewhere, but not exactly where it is deployed or which hosts still expose the vulnerable endpoint.
Then validate network reachability and access boundaries. If the server is bound in a way that makes it reachable from non-developer networks, treat that as a materially higher-risk condition. If the service is only expected on local developer machines, any broader listening scope or forwarding path deserves investigation before assuming the blast radius is small.
- Inventory every host, container, and pipeline that runs the CLI or its development server.
- Check whether the endpoint is reachable from adjacent networks, VPN ranges, or cloud environments.
- Verify whether any development proxy, port-forward, or test harness unintentionally exposes it.
Where the vulnerability is supported by command injection rather than data exposure alone, the most important question is whether an unauthenticated attacker can reach the trigger path. That changes the response from “patch soon” to “reduce exposure now.”
What to do while patching or mitigation is pending
If you cannot remediate immediately, reduce reachability first. Restrict access to trusted developer hosts, remove any unnecessary exposure to shared networks, and disable the vulnerable service path wherever the workflow allows it. For command-injection flaws, segmentation and containment matter because even a short window of exposure can be enough for arbitrary execution.
When the environment must remain available, add compensating controls that reduce the chance of exploitation and make abuse observable. At minimum, watch for unexpected POST activity to the development server, unusual child process creation, and any post-exploitation behaviour that suggests the endpoint was used to launch executables.
Use the vendor advisory and the CISA Known Exploited Vulnerabilities Catalog for authoritative remediation timing, then confirm the fix in a controlled test environment before reintroducing the service into normal developer workflows.
Risk and Threat Considerations
Because this flaw permits arbitrary executable launch through an exposed endpoint, the risk is not limited to the development tool itself. A reachable instance can become a foothold for code execution, lateral movement into build assets, or theft of developer secrets and tokens that sit nearby in the workflow.
Failure mechanism: An attacker sends crafted POST requests to the Metro Development Server and abuses the vulnerable endpoint to execute commands on the host.
Impact: The outcome can range from local system compromise to broader environment abuse if the host has access to source code, credentials, package registries, or other trusted development resources.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Limits reachability of exposed development services. |
| CIS-7 — Continuous Vulnerability Management | Supports prioritizing a KEV-listed exploited vulnerability. | |
| CIS-16 — Application Software Security | Applies to command-injection risk in application tooling. | |
| Recommendation — Segment and restrict access to development servers and build hosts. Prioritise and remediate KEV-listed flaws first. Verify and harden application tooling against command injection. | ||
| OWASP ASVS | V4 — API and Web Service | The vulnerable endpoint is reached through network requests to a service interface. |
| V15 — Secure Coding and Architecture | Command injection is a secure design and implementation failure. | |
| Recommendation — Validate service endpoints for injection and unauthorized execution paths. Remove shell-execution patterns and enforce safe command handling. | ||
Practitioner Guidance
What to verify: Confirm whether any instance of the CLI or Metro Development Server is reachable outside the intended developer boundary, and treat “development only” as insufficient unless the network path is actually closed.
Decision rule: If the service can be reached by systems you would not trust to run arbitrary code on your workstation, prioritise containment and exposure reduction before waiting for a maintenance window.
What to measure: Track how many hosts still expose the vulnerable endpoint, whether those hosts are internet-facing or cross-network reachable, and whether any unexpected command execution telemetry appears around the service.
Practitioner takeaway: For actively exploited command-injection flaws, the right sequence is exposure control first, verification second, and only then normal remediation closure.
Related resources from NHI Mgmt Group
- Guide: Zero-Day and Exploited Vulnerabilities Guide
- CVE-2025-11953 (React Native Community CLI OS Command Injection)
- Is CVE-2025-66644 (Array Networks ArrayOS AG OS Command Injection) being exploited in the wild?
- Is CVE-2018-9276 (Paessler PRTG Network Monitor OS Command Injection) being exploited in the wild?
- Is CVE-2023-28771 (Zyxel Multiple Firewalls OS Command Injection) being exploited in the wild?