CVE-2026-64641

What it actually does

CVE-2026-64641 is a network-reachable denial-of-service flaw in Next.js applications that use the App Router and have at least one Server Action enabled. A crafted HTTP request can trigger excessive CPU consumption in the affected Next.js server process. Because the CPU-bound work occurs inside the application process, the process may become unable to service additional requests, causing availability loss for users sharing that process or worker. The flaw affects Next.js 13.0.0 through 15.5.20 and 16.0.0 through 16.2.10, and is fixed in 15.5.21 and 16.2.11.

Why it matters to the business

Successful exploitation can make affected web applications slow or unavailable without requiring authentication. For public-facing applications, this can result in customer-facing outages, failed transactions, degraded user experience, increased infrastructure cost from autoscaling, and operational load on engineering and support teams. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, but it is easy to reach over the network where vulnerable application patterns are present, so internet-exposed Next.js services should still be prioritized for upgrade.

How an attack unfolds

An attacker first identifies a Next.js application that uses the App Router and includes at least one Server Action. They then send specially crafted HTTP requests to routes or endpoints that cause the vulnerable Server Action request-handling path to perform excessive CPU work. Repeating or parallelizing these requests can pin the Node.js event loop or worker CPU, preventing the same process from handling normal application traffic. In horizontally scaled deployments, an attacker may need to distribute requests across instances or continue sending requests as load balancers route around unhealthy workers. The attack does not require credentials or user interaction, but it does require the application to match the vulnerable configuration.

How to fix it

Upgrade Next.js to a fixed release: use 15.5.21 or later for the 15.x line, or 16.2.11 or later for the 16.x line. Applications on Next.js 13.x or 14.x should upgrade to a supported fixed version rather than remaining on an affected branch. Rebuild and redeploy application artifacts after updating dependencies, because bundled server code may retain the vulnerable framework version until a clean build occurs. If immediate upgrade is not possible, reduce exposure by placing affected applications behind rate limiting, request body/header size limits, bot protections, and WAF rules for anomalous Server Action traffic; increase process isolation and autoscaling safeguards; and consider disabling or refactoring Server Actions where feasible until patched.

How to confirm the fix worked

Confirm the deployed Next.js version is not in the affected ranges by checking package-lock.json, pnpm-lock.yaml, yarn.lock, npm list next, pnpm list next, yarn why next, container image SBOMs, and build artifacts. Validate that production deployments were rebuilt after the dependency update and that running containers or serverless functions are using Next.js 15.5.21 or later, or 16.2.11 or later. Confirm the application either does not use App Router Server Actions or is running a fixed version. Operationally, verify that crafted or malformed Server Action-like requests are rejected, rate-limited, or handled without sustained CPU spikes, event-loop blocking, worker restarts, or elevated 5xx/timeout rates.

Typical attack path

1. Discover a public or reachable web application built with an affected Next.js version.
2. Determine or infer that the application uses the App Router and has Server Actions enabled.
3. Send crafted HTTP requests targeting the Server Action handling path.
4. Repeat or parallelize requests to consume CPU in one or more Node.js/Next.js worker processes.
5. Cause request queues, timeouts, health-check failures, or service unavailability for legitimate users.

How to detect it

To assess prior exploitation, correlate web access logs, CDN/WAF logs, load-balancer logs, application logs, APM traces, and host/container metrics. Look for bursts of unauthenticated POST requests associated with Next.js Server Action handling, especially requests containing Server Action-related headers such as Next-Action or React Server Components indicators, followed by high CPU, Node.js event-loop lag, request timeouts, worker restarts, autoscaling events, or spikes in 5xx responses. Investigate source IPs or ASNs that generate repeated low-volume but CPU-expensive requests, requests with unusual header combinations, abnormal request bodies, or repeated failures against App Router paths. In containerized or serverless environments, review orchestrator events for health-check failures, restarts, throttling, or concurrency exhaustion that align with suspicious HTTP traffic. Because this is a denial-of-service issue, durable host artifacts may be limited; the strongest evidence is timing correlation between crafted request patterns and CPU/process saturation.

• Next-Action
• RSC
• text/x-component
• _rsc=
• next-router-state-tree
• next-url
• next-server
• node
• HTTP 503
• HTTP 504
• upstream timed out
• upstream prematurely closed connection
• event loop lag
• CPU throttling
• OOMKilled
• CrashLoopBackOff

What your security team should do

• Inventory all Next.js applications and identify those running versions 13.0.0 through 15.5.20 or 16.0.0 through 16.2.10.
• Prioritize internet-facing applications that use App Router and Server Actions for immediate upgrade to Next.js 15.5.21, 16.2.11, or later.
• Rebuild and redeploy affected applications from clean dependency installs to ensure patched framework code is actually running.
• Add or tune rate limits, WAF controls, and request anomaly detection for Server Action traffic, especially unauthenticated POST requests with unusual headers, sizes, or repetition patterns.
• Monitor application CPU, Node.js event-loop lag, request latency, 499/500/502/503/504 responses, and load-balancer health-check failures for signs of attempted denial of service.
• Review logs from the period since publication for bursts of suspicious Server Action-related requests correlated with CPU saturation or application unavailability.
• Track vendor advisories and dependency scanning results because downstream packages or templates may pin vulnerable Next.js versions.