Is CVE-2025-55182 (Meta React Server Components Remote Code Execution) being exploited in the wild?

Yes. CISA added CVE-2025-55182 to its Known Exploited Vulnerabilities catalogue on 5 December 2025, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. Meta React Server Components contains a remote code execution vulnerability that could allow unauthenticated remote code execution by exploiting a flaw in how React decodes payloads sent to React Server Function endpoints.

What the KEV listing tells you about exploitation status

The practical answer is yes, and the KEV listing is the signal that matters operationally. For exposed Meta React Server Components deployments, treat the issue as an active exploitation problem, not a theoretical flaw. The first step is confirming whether your environment uses the affected React Server Components path and whether any internet-facing service can reach it.

Because CISA only adds a CVE to KEV when it has reliable evidence of active exploitation, the listing should move this issue into immediate response rather than normal patch planning. If the vulnerable endpoint is externally reachable, assume adversaries may already be scanning for it and that exploitation could be unauthenticated.

Why this vulnerability is operationally dangerous

This is a remote code execution flaw, which means the security impact is not limited to data exposure. If the vulnerable React Server Components decoding path is reachable, an attacker may be able to execute code on the server without prior authentication, then use that foothold to pivot into application secrets, session material, deployment credentials, or adjacent systems.

The biggest operational mistake is to treat front-end framework vulnerabilities as lower priority than infrastructure flaws. Server-side framework code often sits close to build pipelines, runtime configuration, internal APIs, and cloud metadata, so compromise can quickly expand beyond the application tier.

For response planning, the key question is not only whether exploitation is possible, but whether the compromised process has access to secrets, signing material, or internal service credentials that would turn a single RCE into broader environment compromise.

What to do if you cannot patch immediately

If patching or redeployment must wait, reduce exposure first. Restrict public access to the affected service, place compensating filtering or WAF rules in front of the endpoint where feasible, and monitor for abnormal request patterns against React Server Function endpoints and unexpected server-side process behaviour.

Use the vendor advisory and the CISA Known Exploited Vulnerabilities Catalog for the authoritative remediation path, and verify versions there rather than relying on copied guidance. For triage and prioritisation, the Zero-Day and Exploited Vulnerabilities Guide is useful because it ties KEV status to emergency response, compromise assessment, and post-fix hunting.

Where the server process can reach secrets or privileged back-end services, rotate the most exposed credentials after containment, especially tokens, API keys, and signing material that the application may have loaded into memory or cached on disk.

Risk and Threat Considerations

Active exploitation changes the risk model from “potentially dangerous” to “likely being weaponised now.” In practice, unauthenticated RCE means attackers do not need a valid account, which makes internet exposure and weak edge controls the main failure conditions rather than user error.

Failure mechanism: The flaw sits in how React decodes payloads sent to React Server Function endpoints, so a crafted request can reach server-side execution logic that was not meant to accept hostile input.

Impact: If exploitation succeeds, attackers can execute server-side code, inspect local secrets, tamper with application behaviour, and use the compromised host as a staging point for broader intrusion or ransomware-related activity.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	DE.CM-01 — Networks and network services are monitored to find potential cybersecurity events	Active exploitation requires monitoring for suspicious inbound activity and exploit attempts.
Recommendation — Monitor exposed endpoints for exploit patterns and anomalous server-side requests.
NIST SP 800-53 Rev 5	SI-4 — System Monitoring	RCE exploitation needs detection of malicious server activity and post-exploit behaviour.
Recommendation — Review server telemetry and alert on abnormal execution or request patterns.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-listed RCEs demand rapid identification, prioritisation, and remediation of exposed assets.
Recommendation — Prioritise exposed instances for emergency remediation and verification.
OWASP ASVS	V15 — Secure Coding and Architecture	The issue is a server-side code execution flaw in application architecture and parsing logic.
Recommendation — Review server-side parsing paths and harden the application architecture against hostile input.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	The vulnerability is exploitable through an externally reachable server endpoint.
Recommendation — Map the vulnerable endpoint as a public-facing application and hunt for exploitation attempts.

Practitioner Guidance

What to verify: Confirm whether any production or pre-production service exposes React Server Components over a reachable endpoint, then check whether server logs show unusual requests, unexpected decoding errors, or command-like post-exploitation activity. If you cannot verify exposure quickly, treat the service as potentially affected until proven otherwise.

Decision rule: If the affected service can execute with access to secrets, internal APIs, or deployment infrastructure, prioritise containment, patching, and secret rotation before deeper forensic work; if the service is isolated and holds no sensitive material, containment still comes first, but blast-radius assessment becomes narrower.

Practitioner takeaway: KEV status means this is a response event, not a watch item, so the priority is to confirm exposure, shrink the reachable attack surface, and assume compromise until logs and host evidence show otherwise.