CVE-2026-23870: 
React Server Components vulnerability analysis and mitigation

CVE-2026-23870 is a Denial of Service (DoS) vulnerability in React Server Components packages that allows unauthenticated remote attackers to trigger out-of-memory exceptions or excessive CPU usage by sending specially crafted HTTP requests to server function endpoints. It was published on May 6, 2026, and affects react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack in versions 19.0.0–19.0.5, 19.1.0–19.1.6, and 19.2.0–19.2.5. The vulnerability was assigned by Meta and carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, React Security Advisory).

The root cause is classified under CWE-400 (Uncontrolled Resource Consumption) and CWE-770 (Allocation of Resources Without Limits or Throttling), meaning the affected packages fail to impose adequate restrictions on resource allocation when processing incoming requests at server function endpoints. An unauthenticated attacker can send specially crafted HTTP requests to these endpoints, causing the server to allocate unbounded memory or consume excessive CPU cycles, ultimately leading to service crashes or severe degradation. No authentication or user interaction is required, and the attack complexity is low, making this straightforward to exploit over the network. Applications that do not use a server or do not leverage React Server Components (RSC) via a supported framework or bundler plugin are not affected (GitHub Advisory, React Security Advisory).

Successful exploitation results in a complete loss of availability for the affected server, manifesting as out-of-memory crashes or sustained CPU exhaustion that renders the application unresponsive. There is no confidentiality or integrity impact — the vulnerability is purely a DoS condition. Any application using the affected RSC packages with a server-side rendering setup is at risk, potentially affecting end users of production Next.js, Parcel, or Turbopack-based React applications (GitHub Advisory, Imperva Blog).

A proof-of-concept exploit is publicly available on GitHub (targeting Next.js v16.2.4 and related RSC vulnerabilities across multiple CVEs), including runnable exploit.sh and exploit.py scripts (PoC Repository). Additionally, a dedicated checker tool has been published (Checker Tool). As of the time of reporting, there is no confirmed evidence of active in-the-wild exploitation, and no threat actor attribution has been made. The EPSS score is approximately 0.39% (60th percentile), indicating a moderate near-term exploitation probability. The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (GitHub Advisory).

1. Reconnaissance: Identify internet-facing applications using react-server-dom-webpack, react-server-dom-parcel, or react-server-dom-turbopack in versions 19.0.0–19.0.5, 19.1.0–19.1.6, or 19.2.0–19.2.5. Tools like Shodan, Censys, or package manifest scanning can help identify targets running Next.js or similar RSC-enabled frameworks.
2. Identify server function endpoints: Locate exposed React Server Component action/function endpoints (e.g., endpoints that accept serialized RSC payloads or server action invocations), typically accessible via POST requests to framework-specific routes.
3. Craft malicious HTTP request: Construct a specially crafted HTTP request — such as an oversized, deeply nested, or otherwise malformed payload — targeting the server function endpoint. Public PoC scripts (e.g., from dwisiswant0/next-16.2.4-pocs) provide concrete payload templates.
4. Send request to trigger resource exhaustion: Transmit the crafted request to the target endpoint. The server's RSC runtime processes the payload without adequate resource limits, triggering out-of-memory exceptions or CPU saturation.
5. Sustain DoS: Repeat or flood requests to maintain the denial-of-service condition, preventing legitimate users from accessing the application (PoC Repository, GitHub Advisory).

• Network: Unusual volume of HTTP POST requests to server function or RSC action endpoints; requests with abnormally large or deeply nested payloads targeting Next.js or RSC-enabled routes.
• Logs: Server access logs showing repeated requests to RSC endpoints from a single or rotating set of IP addresses; application logs recording out-of-memory (OOM) errors or heap exhaustion events correlated with incoming HTTP traffic.
• Process/System: Node.js process consuming abnormally high CPU (near 100%) or memory (approaching system limits) without corresponding legitimate traffic spikes; frequent process restarts or crashes of the Node.js server process.
• Application: Sudden unavailability or extreme latency of server-rendered React pages; OOM kill events in container orchestration logs (e.g., Kubernetes OOMKilled status) (Imperva Blog, GitHub Advisory).

Upgrade the affected packages immediately to the patched versions: react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack version 19.0.6, 19.1.7, or 19.2.6 (matching your current minor version line). Applications that do not use a server or do not use a framework/bundler with React Server Components support are not affected and require no action. As a temporary workaround prior to patching, consider placing a WAF or rate-limiting proxy (e.g., Cloudflare, Imperva) in front of RSC endpoints to restrict request size and rate (GitHub Advisory, Cloudflare Changelog, Imperva Blog).

Imperva published a blog post confirming that their WAF customers are protected against this vulnerability and providing technical context on the DoS risk (Imperva Blog). Cloudflare and Netlify both issued changelog entries noting protections or guidance for their customers hosting Next.js/RSC applications (Cloudflare Changelog, Netlify Changelog). Vercel published a dedicated security release note for Next.js covering this and related vulnerabilities (Vercel Changelog). Community discussion on Reddit and security forums highlighted concerns about the speed of exploit development relative to patch adoption, with some developers publicly reconsidering RSC adoption in light of the vulnerability class.