CVE-2026-64646

What it actually does

The flaw is a network-reachable denial-of-service condition in Next.js applications that use the App Router and have at least one Server Action running on the Edge runtime. Specially crafted or repeated requests to affected Server Action handling paths can cause excessive memory consumption in the application runtime. The primary impact is reduced availability: worker processes, serverless/edge isolates, containers, or hosting instances may slow down, be killed by memory limits, restart, or fail to serve legitimate traffic. The issue 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 intermittently unavailable or noticeably slower, which can disrupt customer-facing services, internal portals, APIs backed by Next.js routes, checkout flows, authentication journeys, or other business workflows served by the application. The current public exploitation signal is low: EPSS is 0.00531, it is not listed in CISA KEV, no ransomware use is reported, and exploit maturity is listed as none. However, because exploitation is unauthenticated and network-accessible under the affected configuration, internet-facing applications using App Router Server Actions on the Edge runtime should still be prioritized for upgrade, especially where downtime has revenue, operational, or SLA consequences.

How an attack unfolds

An attacker first identifies a Next.js application using the App Router and probes for behavior consistent with Server Actions, commonly by observing client-side React Server Component traffic and Server Action request patterns. If the application has at least one Server Action configured to run on the Edge runtime and is on an affected Next.js version, the attacker sends crafted or high-volume requests to the relevant action endpoints or pages that trigger Server Action handling. The vulnerable runtime path consumes excessive memory while processing those requests. As memory pressure increases, the affected edge isolate, serverless function, Node process, container, or hosting worker may degrade, be terminated by the platform, or restart repeatedly. The attacker can sustain impact by repeating requests, causing service instability without needing authentication, user interaction, or code execution.

How to fix it

Upgrade Next.js to a fixed version. Applications on the 15.x line should upgrade to Next.js 15.5.21 or later. Applications on the 16.x line should upgrade to Next.js 16.2.11 or later. Applications still on 13.x or 14.x should move to a maintained fixed release line, such as 15.5.21 or later, after compatibility testing. Rebuild and redeploy all affected applications, including serverless, edge, container, and static hosting deployments that bundle Next.js at build time. If immediate upgrade is not possible, reduce exposure by moving affected Server Actions off the Edge runtime where feasible, disabling or refactoring unnecessary Server Actions, adding request rate limits and body-size limits, requiring authentication before expensive action paths, and placing WAF/CDN controls in front of public applications. Monitor memory utilization and restart frequency until the fixed build is deployed.

How to confirm the fix worked

Confirm the deployed package version, not only the repository version. Check package-lock.json, pnpm-lock.yaml, yarn.lock, package.json, build artifacts, SBOMs, and runtime dependency inventory for Next.js versions in the affected ranges: 13.0.0 through 15.5.20 and 16.0.0 through 16.2.10. Validate that production deployments are running Next.js 15.5.21 or later on the 15.x line, or 16.2.11 or later on the 16.x line. Review application code for Server Actions using the Edge runtime, including files or route segments declaring runtime = 'edge'. After upgrade, run functional tests for App Router pages and Server Actions, then perform controlled load testing against Server Action flows while monitoring memory, worker restarts, HTTP 5xx rates, and request latency. Confirm no unexpected memory growth occurs under representative POST traffic.

Typical attack path

1. Find an internet-accessible application built with an affected Next.js version.
2. Determine whether the application uses the App Router and exposes Server Action request behavior.
3. Identify request paths or pages that can invoke a Server Action running on the Edge runtime.
4. Send crafted or repeated unauthenticated requests that trigger the vulnerable Server Action handling path.
5. Drive excessive memory consumption in the edge/serverless/application runtime.
6. Cause worker termination, container restarts, request timeouts, elevated error rates, or intermittent application unavailability.
7. Continue the request pattern to prolong service degradation until traffic is blocked, rate-limited, or the application is patched.

How to detect it

To assess whether exploitation may already have occurred, correlate web access logs, CDN/WAF logs, application logs, edge/serverless platform logs, container orchestration events, and infrastructure metrics. Look for sudden increases in POST requests to App Router pages or Server Action flows, especially requests containing Next-Action or related React Server Component headers, followed by memory spikes, garbage collection pressure, worker crashes, cold starts, container restarts, or HTTP 5xx/timeout bursts. Review logs for repeated requests from a small set of IPs, unusual user agents, high request concurrency, abnormal request body sizes, and requests that consistently precede out-of-memory events. In hosting platforms, inspect function invocation logs for memory limit exceedance, isolate termination, and repeated restarts. Because no unique public exploit payload or actor-specific indicator is available, detection should focus on behavioral correlation between Server Action request patterns and resource exhaustion.

• Next-Action
• next-action
• RSC: 1
• text/x-component
• multipart/form-data
• application/x-www-form-urlencoded
• FATAL ERROR: Reached heap limit Allocation failed
• JavaScript heap out of memory
• Allocation failed - JavaScript heap out of memory
• Out of memory
• ENOMEM
• memory limit exceeded
• Container killed due to memory usage
• OOMKilled
• signal: killed
• exit code 137
• HTTP 500
• HTTP 502
• HTTP 503
• HTTP 504

What your security team should do

• Inventory all Next.js applications and identify those using App Router, Server Actions, and the Edge runtime.
• Prioritize internet-facing and business-critical applications running Next.js 13.0.0 through 15.5.20 or 16.0.0 through 16.2.10.
• Upgrade affected applications to Next.js 15.5.21 or 16.2.11 or later, rebuild artifacts, and redeploy production workloads.
• If patching is delayed, temporarily move Server Actions away from the Edge runtime where practical and enforce CDN/WAF rate limiting on Server Action traffic.
• Add monitoring and alerting for memory saturation, out-of-memory kills, container or function restarts, request timeouts, and spikes in HTTP 500/502/503/504 responses.
• Review recent access logs for bursts of POST requests containing Server Action indicators such as Next-Action headers, especially when correlated with memory spikes or restarts.
• Ensure dependency scanners and SBOM tooling flag the affected Next.js version ranges across repositories and built images.
• Because the vulnerability is recently published but not currently KEV-listed and has low EPSS, treat remediation as high priority for exposed critical apps and scheduled priority for lower-risk internal apps.