Denial of service in server functions affecting Meta React Server DOM

A denial of service vulnerability could be triggered by sending specially crafted HTTP requests to server function endpoints, this could lead to excessive CPU usage; affecting the following packages: react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack (versions 19.0.0 through 19.0.7, 19.1.0 through 19.1.8, and 19.2.0 through 19.2.7).

Meta records the default status as unaffected outside the following explicit ranges:

• react-server-dom-webpack: affected from 19.0.0 through 19.0.7, from 19.1.0 through 19.1.8, and from 19.2.0 through 19.2.7.
• react-server-dom-parcel: affected from 19.0.0 through 19.0.7, from 19.1.0 through 19.1.8, and from 19.2.0 through 19.2.7.
• react-server-dom-turbopack: affected from 19.0.0 through 19.0.7, from 19.1.0 through 19.1.8, and from 19.2.0 through 19.2.7.

The vendor advisory states that fixes were backported to 19.0.8, 19.1.9, and 19.2.8. However, the advisory's structured package data lists the 19.0.x affected branch for react-server-dom-webpack and react-server-dom-turbopack, but not for react-server-dom-parcel, while the advisory narrative still names react-server-dom-parcel in the affected 19.0.x set. Treat the status of react-server-dom-parcel 19.0.x as an inconsistency requiring vendor confirmation rather than assuming that branch is safe.

The affected packages are react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack, which can be used in server-side React Server Components flows.

1. An attacker sends specially crafted HTTP requests to reachable server function endpoints over the network.
2. Processing those requests can consume excessive CPU or trigger out-of-memory exceptions.
3. The resulting resource exhaustion can degrade or interrupt the availability of the service handling React Server Components.

The available evidence is consistent with uncontrolled resource consumption and allocation of resources without limits or throttling. The record indicates that exploitation does not require authentication, has low complexity, and does not require user interaction. The exact request structure, parsing condition, vulnerable function, and resource-accounting logic are not disclosed, so a more specific exploit path cannot be confirmed.

The vulnerability is remotely reachable over the network when a server function endpoint is exposed and processes external requests. The normalized record indicates that exploitation requires no privileges or authentication, has low complexity, and requires no user interaction.

The normalized record marks public_exploit as false and does not provide a known_exploited designation. CISA ADP data reflected in GCVE records exploitation as none. This is a status signal within the available evidence and does not prove that exploitation is impossible. No specific public exploit, campaign, victim, or indicator is identified in the supplied evidence.

• Technical outcome: specially crafted requests can cause uncontrolled resource consumption, excessive CPU usage, or out-of-memory exceptions.
• Privilege scope: the record indicates that exploitation requires no privileges or authentication and no user interaction.
• Availability: the process, worker, or service handling server functions may slow down, restart, or stop responding when resources are exhausted.
• Impact limit: the available evidence confirms an availability effect but does not confirm the ability to read or modify data.
• Organizational scope: applications or APIs dependent on server-side React Server Components may be affected, while client-only React code is excluded under the advisory's stated condition.

• Malicious requests can sharply increase CPU or memory consumption in the process handling React Server Components.
• The service may become slow, restart after out-of-memory failures, or lose availability when server resources are exhausted.
• The confirmed operational impact is concentrated on server function availability; the available evidence does not indicate confidentiality or integrity impact.
• Actual exposure depends on whether the deployment uses server-side React Server Components and exposes the corresponding endpoints.

1. Upgrade affected packages to the exact fixed release for their branch: use 19.0.8 for the 19.0.x branch, 19.1.9 for the 19.1.x branch, and 19.2.8 for the 19.2.x branch.
2. Check both direct and transitive dependencies in lockfiles, manifests, and deployment artifacts. Checking only a higher-level React package may miss indirectly installed react-server-dom-* packages.
3. For react-server-dom-parcel 19.0.x, do not treat the branch as unaffected merely because the advisory's structured package data omits it. The vendor narrative names that branch as affected and lists 19.0.8 as a backport, so upgrade to the corresponding fixed release if the package is used, or obtain vendor confirmation if the branch cannot be upgraded.
4. After updating, verify applications that expose server function endpoints and use React Server Components, then redeploy so the running process uses the fixed package.
5. The supplied evidence does not provide a specific compensating mitigation. Access restrictions or resource controls may be used as defense in depth, but they should not replace the vendor update or be treated as a confirmed fix.

• Inventory direct and transitive dependencies to determine whether react-server-dom-webpack, react-server-dom-parcel, or react-server-dom-turbopack is installed.
• Compare deployed versions from lockfiles, manifests, and package metadata with the affected ranges: 19.0.0 through 19.0.7, 19.1.0 through 19.1.8, and 19.2.0 through 19.2.7.
• Determine whether the application uses a server, React Server Components, server function endpoints, or a framework, bundler, or bundler plugin that supports React Server Components.
• Review CPU and memory spikes, out-of-memory failures, process restarts, or availability degradation that coincide with requests to server function endpoints. These are defensive review signals, not vendor-confirmed indicators of compromise.
• Do not treat the absence of relevant logs or resource failures as proof that the deployment is safe.