A high-severity React Server Components denial-of-service flaw can let unauthenticated attackers degrade vulnerable Next.js App Router apps through crafted Server Function requests.
A high-severity denial-of-service vulnerability in React Server Components can allow unauthenticated attackers to crash or degrade vulnerable server-side React applications by sending crafted HTTP requests to Server Function endpoints. Tracked as CVE-2026-23870, the flaw affects react-server-dom-* packages in React 19 release lines and downstream frameworks including Next.js App Router deployments.
The vulnerability carries a CVSS 7.5 High rating with the vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, meaning it is network-exploitable, low-complexity, requires no login, needs no user interaction and primarily affects availability. Successful exploitation can trigger excessive CPU usage, out-of-memory exceptions, server hangs or process crashes.
The immediate fix is straightforward: upgrade affected React Server Components packages to 19.0.6, 19.1.7 or 19.2.6, depending on the application’s React minor line. Next.js users running App Router should upgrade to patched Next.js versions, at minimum 15.5.16 or 16.2.5, with later patch releases preferred where available. The same upgrade urgency applies broadly this year, with Microsoft's July Patch Tuesday hitting a record 622 CVEs.
What Is Affected
The upstream vulnerability sits in the React Server Components package family used to support server-side component rendering and Server Functions. Client-only React apps are not automatically exposed. The risk applies when an application runs React on the server through tooling that supports React Server Components or Server Functions.
| Component | Vulnerable versions | Fixed versions |
|---|---|---|
react-server-dom-webpack | 19.0.0–19.0.5, 19.1.0–19.1.6, 19.2.0–19.2.5 | 19.0.6, 19.1.7, 19.2.6 |
react-server-dom-parcel | 19.0.0–19.0.5, 19.1.0–19.1.6, 19.2.0–19.2.5 | 19.0.6, 19.1.7, 19.2.6 |
react-server-dom-turbopack | 19.0.0–19.0.5, 19.1.0–19.1.6, 19.2.0–19.2.5 | 19.0.6, 19.1.7, 19.2.6 |
next with App Router | >=13.0.0 <15.5.16, >=16.0.0 <16.2.5 | 15.5.16, 16.2.5 |
The most common real-world exposure is likely to be Next.js App Router, because App Router applications can expose Server Function endpoints backed by the affected React Server Components stack. Older Next.js 13.x and 14.x deployments should not assume they will receive backported fixes; teams should move to a supported patched line.
How the Attack Works
Public advisories describe the trigger as a specially crafted HTTP request sent to a Server Function endpoint. When the vulnerable server deserializes the request, it may allocate resources without sufficient throttling or enter expensive processing paths that consume excessive CPU or memory.
The issue is not a data-theft bug. The CVSS vector records no confidentiality or integrity impact. That does not make it harmless. Availability-only flaws can still take customer-facing applications offline, exhaust serverless budgets, force container restarts or create cascading failures behind load balancers. Other recent flaws are worse in kind: a compromised Trivy CI/CD scanner release stole credentials outright rather than just degrading uptime.
Security teams should avoid conflating CVE-2026-23870 with earlier React Server Components vulnerabilities disclosed in late 2025 and early 2026. Those issues are related by component family and attack surface, but CVE-2026-23870 has its own affected version ranges and patch levels.
How to Reproduce Safely
A responsible reproduction should confirm exposure and patch effectiveness without publishing or running a weaponized denial-of-service payload against production systems. The public primary advisories do not provide an official exploit body, and defenders do not need one to identify vulnerable deployments. That distinction matters more as open-source vulnerability clearinghouses strain under record CVE volume.
Start by checking dependency versions in a controlled environment:
npm ls next react react-dom \
react-server-dom-webpack \
react-server-dom-parcel \
react-server-dom-turbopack
For pnpm or Yarn:
pnpm why next
pnpm why react-server-dom-webpack
pnpm why react-server-dom-parcel
pnpm why react-server-dom-turbopack
yarn why next
yarn why react-server-dom-webpack
A vulnerable dependency tree might include:
next@15.5.15
react-server-dom-webpack@19.1.6
That combination is exposed because next@15.5.15 is below the patched 15.5.16 release and react-server-dom-webpack@19.1.6 is below the fixed 19.1.7 release.
Next, confirm whether the application uses App Router and Server Functions:
find app -type f \( -name "*.js" -o -name "*.jsx" -o -name "*.ts" -o -name "*.tsx" \) \
-exec grep -nH "'use server'\|\"use server\"" {} \;
Likely exposure indicators include:
- An
app/directory in a Next.js project. - Server Actions or Server Functions using
'use server'. - Installed vulnerable
nextorreact-server-dom-*versions. - Publicly reachable endpoints backed by App Router Server Functions.
For non-destructive validation, build and run the app locally or in an isolated staging environment:
npm run build
npm run start
Then run a normal smoke test:
curl -i http://localhost:3000/
Monitor baseline CPU, memory and process behavior during ordinary requests:
top -o cpu
docker stats
pm2 monit
Do not run crafted payloads against production, third-party applications, shared hosting, public preview deployments or customer-facing environments. If an internal red team validates exploitability, it should do so only in an isolated lab using an approved test app and should compare vulnerable and patched versions under controlled monitoring.
How to Fix
For direct React Server Components users, upgrade the affected package to the patched version matching the current React minor line:
# React 19.0.x line
npm install react-server-dom-webpack@19.0.6
# React 19.1.x line
npm install react-server-dom-webpack@19.1.7
# React 19.2.x line
npm install react-server-dom-webpack@19.2.6
If the application uses Parcel or Turbopack RSC packages, upgrade those as well:
npm install react-server-dom-parcel@19.2.6
npm install react-server-dom-turbopack@19.2.6
For Next.js App Router applications, upgrade Next.js:
npm install next@15.5.16
# or
npm install next@16.2.5
Where possible, move to the newest patch release in the supported line, such as:
npm install next@15.5.18
# or
npm install next@16.2.6
After changing versions, perform a clean install and rebuild:
rm -rf node_modules
npm install
npm run build
npm test
npm audit --omit=dev
npm ls next react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack
Finally, redeploy every live environment, not only the main production deployment. Staging environments, branch deployments, preview builds, serverless functions and edge/server rendering environments can continue running vulnerable immutable builds even after the main branch is patched. The same blind spot shows up in Jenkins as the software factory's high-privilege control plane, where a single unpatched plugin lingers unnoticed.
Temporary Mitigations
Upgrading is the only reliable fix. If a same-day upgrade is blocked, teams can reduce exposure while preparing the patch:
| Mitigation | Value | Limitation |
|---|---|---|
| Restrict access to Server Function endpoints | Reduces unauthenticated reachability | May break public app flows |
| Rate-limit suspicious POST traffic | Slows repeated DoS attempts | One request may still be expensive |
| Enforce request body limits | Helps against oversized payloads | Does not stop all CPU-heavy inputs |
| Add WAF rules for RSC/Server Function abuse patterns | Blocks known signatures | Variants may bypass generic rules |
| Set worker CPU and memory limits | Contains process-level blast radius | Users may still see 5xx errors |
| Review serverless concurrency and cost alerts | Limits operational surprise | Does not remove vulnerability |
Detection should focus on symptoms: sudden CPU spikes, heap growth, out-of-memory logs, repeated POST requests to App Router or Server Function endpoints, bursts of 5xx responses and increased serverless duration or cost.
Useful triage commands include:
grep -Ei 'POST|multipart/form-data|text/x-component|_rsc|server' access.log \
| awk '{print $1}' \
| sort | uniq -c | sort -nr | head
grep -Ei 'out of memory|heap|cpu|timeout|server action|server function|react-server-dom' app.log
kubectl top pods
kubectl logs deploy/nextjs-deployment-name --since=2h | grep -Ei 'heap|memory|timeout|react-server-dom'
CVE-2026-23870 is a reminder that server-side component frameworks have become part of the application attack surface, not merely developer tooling. Teams that adopted React Server Components or Next.js App Router should treat RSC package versions as production security dependencies, verify transitive updates through lockfiles, and redeploy all exposed environments after patching. The same lockfile discipline matters for the Mini Shai-Hulud npm supply-chain worm that abused trusted publishing.