CVE-2025-55184

What it actually does

This is a denial-of-service flaw in React Server Components processing affecting react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack versions 19.0.0, 19.0.1, 19.1.0, 19.1.1, 19.1.2, 19.2.0, and 19.2.1, including downstream use in Next.js. A remote attacker can send specially crafted React Server Components traffic that causes excessive server-side resource consumption or request handling failure, degrading or exhausting application availability. The issue does not inherently imply code execution or data disclosure, but it can make affected server-rendered routes and application backends unavailable under sustained attack.

Why it matters to the business

Successful exploitation can cause public web applications using affected React Server Components packages to become slow, unstable, or unavailable, leading to customer-facing outages, failed transactions, elevated infrastructure costs from autoscaling, and incident response disruption. The risk is elevated because exploit maturity is listed as weaponized and the EPSS probability is high, even though the issue is not currently listed in CISA KEV and is not known to be ransomware-associated. Organizations using Next.js or React Server Components in internet-facing applications should treat remediation as urgent because denial-of-service flaws in popular web frameworks can be exploited at scale with relatively low attacker cost.

How an attack unfolds

An attacker first identifies an application that uses React Server Components, commonly through framework behavior, response headers, JavaScript assets, route patterns, package disclosures, or observable RSC request traffic. They then send crafted RSC/Flight requests to routes handled by the vulnerable server-side React implementation. The malicious requests trigger inefficient or unsafe processing in the vulnerable React Server Components package, causing high CPU, memory pressure, request queue saturation, worker crashes, or repeated 5xx responses. By repeating the requests from one or more clients, the attacker can keep application workers busy or unstable, preventing legitimate users from receiving timely responses. In hosted or autoscaled environments, the same activity may also drive resource consumption and cost before rate limits or platform protections take effect.

How to fix it

Upgrade affected React Server Components packages immediately. Ensure react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack are not on versions 19.0.0, 19.0.1, 19.1.0, 19.1.1, 19.1.2, 19.2.0, or 19.2.1. For Next.js source deployments, incorporate the upstream fix identified as commit fc9d731d04b677e07fd54f8a7cc4d2e7d0955731 or a release that contains it. Rebuild and redeploy applications after dependency updates, including lockfile refreshes, because vulnerable transitive versions may remain pinned. Where immediate upgrade is not possible, reduce exposure by placing affected applications behind a CDN/WAF, enabling aggressive rate limiting on RSC/Flight request patterns, limiting request body size and concurrency, enforcing per-IP and per-session throttles, and configuring autoscaling and circuit breakers to prevent resource exhaustion. Mitigations should be treated as temporary; the durable fix is to run patched packages.

How to confirm the fix worked

Confirm dependency remediation by inspecting package manifests and lockfiles for react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack and verifying no affected 19.x versions remain installed. For Next.js builds from source, verify the deployed code includes commit fc9d731d04b677e07fd54f8a7cc4d2e7d0955731 or a later fixed revision. Run package manager inventory commands such as npm ls, pnpm why, or yarn why for the affected package names in every application build. Rebuild containers or deployment artifacts from clean dependency caches and confirm runtime images do not contain stale node_modules directories. After deployment, perform controlled load and regression testing against RSC-enabled routes to ensure normal requests complete without elevated error rates, memory growth, or worker crashes. Validate edge controls by confirming rate limits and request-size limits apply to RSC/Flight traffic without blocking legitimate application behavior.

Typical attack path

1. Identify an internet-facing application using React Server Components, Next.js, or affected react-server-dom-* packages.
2. Locate routes or endpoints that process React Server Components or Flight requests, often indicated by RSC-related headers or query parameters.
3. Send crafted requests that exercise the vulnerable React Server Components deserialization/rendering path.
4. Increase request rate, concurrency, or distribution across source IPs to amplify CPU, memory, or worker exhaustion.
5. Monitor for slow responses, connection resets, 5xx errors, or availability degradation and continue traffic to sustain the outage.

How to detect it

To determine whether exploitation has already occurred, review web access logs, CDN/WAF logs, application logs, process supervisor logs, container orchestration events, and infrastructure metrics around periods of elevated latency or outage. Focus on abnormal bursts of requests to React Server Components or Flight-enabled routes, especially requests containing the RSC header, Next.js router state headers, or _rsc query parameters, followed by spikes in HTTP 500/502/503/504 responses, request timeouts, worker crashes, memory exhaustion, or CPU saturation. Compare source IPs, user agents, request rates, and geographic distribution against normal application traffic; denial-of-service exploitation may appear as high-frequency repeated requests from a small set of hosts or distributed low-and-slow traffic across many hosts. In Node.js and container logs, look for out-of-memory kills, event loop stalls, unhandled exceptions in server rendering paths, repeated restarts, and autoscaling anomalies temporally correlated with RSC traffic. Because the public description does not provide a stable exploit payload signature, detection should be behavior-based rather than relying solely on a single byte pattern.

• react-server-dom-webpack@19.0.0
• react-server-dom-webpack@19.0.1
• react-server-dom-webpack@19.1.0
• react-server-dom-webpack@19.1.1
• react-server-dom-webpack@19.1.2
• react-server-dom-webpack@19.2.0
• react-server-dom-webpack@19.2.1
• react-server-dom-parcel@19.0.0
• react-server-dom-parcel@19.0.1
• react-server-dom-parcel@19.1.0
• react-server-dom-parcel@19.1.1
• react-server-dom-parcel@19.1.2
• react-server-dom-parcel@19.2.0
• react-server-dom-parcel@19.2.1
• react-server-dom-turbopack@19.0.0
• react-server-dom-turbopack@19.0.1
• react-server-dom-turbopack@19.1.0
• react-server-dom-turbopack@19.1.1
• react-server-dom-turbopack@19.1.2
• react-server-dom-turbopack@19.2.0
• react-server-dom-turbopack@19.2.1
• "RSC: 1"
• "Next-Router-State-Tree"
• "Next-Router-Prefetch"
• "_rsc="
• "JavaScript heap out of memory"
• "Allocation failed - JavaScript heap out of memory"
• "FATAL ERROR: Reached heap limit"
• "OOMKilled"
• "HTTP/1.1 503"
• "HTTP/1.1 504"

What your security team should do

• Prioritize inventory of all internet-facing Next.js and React Server Components applications and identify any use of react-server-dom-webpack, react-server-dom-parcel, or react-server-dom-turbopack affected versions.
• Patch or rebuild affected applications immediately, giving highest priority to externally reachable, revenue-generating, authentication, checkout, and API-adjacent web properties.
• Add temporary WAF/CDN/rate-limit protections for RSC/Flight request patterns while upgrades are being tested and rolled out.
• Hunt for signs of prior denial-of-service attempts, including spikes in RSC-related requests, abnormal 5xx responses, worker restarts, memory exhaustion, and high request concurrency from limited source networks.
• Update software composition analysis policies to flag the affected package versions and fail builds that reintroduce them.
• Ensure incident responders and SRE teams have dashboards for request volume, latency, 5xx rate, process restarts, memory usage, CPU saturation, and autoscaling events for affected applications.
• Because exploit maturity is weaponized and EPSS is high, treat unpatched exposure as time-sensitive even though the vulnerability is not currently in CISA KEV.