CVE-2026-27979

What it actually does

In affected Next.js versions 16.0.1 through before 16.1.7, applications using the App Router with Partial Prerendering enabled can incorrectly buffer request bodies for requests containing the `next-resume: 1` header without consistently enforcing the intended postponed-state size limit. Because this header path corresponds to PPR resume handling and is not meant to be accepted from untrusted clients, a remote unauthenticated attacker can send oversized POST bodies that are retained in memory. The result is excessive memory consumption, process instability, degraded availability, or denial of service for vulnerable non-minimal deployments.

Why it matters to the business

Public-facing Next.js applications using vulnerable versions and Partial Prerendering may be taken offline or made unreliable by inexpensive unauthenticated HTTP requests. Successful exploitation can cause elevated hosting costs, failed user transactions, degraded customer experience, autoscaling churn, incident response effort, and potential breach of service-level commitments. 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 remains operationally important because exploitation is network-accessible, low-complexity, and can affect internet-facing web applications.

How an attack unfolds

An attacker first identifies a Next.js application running an affected 16.x release with App Router and Partial Prerendering-related functionality enabled. They then send POST requests to application routes with the `next-resume: 1` header and unusually large request bodies. In vulnerable non-minimal deployment paths, the server treats these as postponed resume-body data and buffers the payload without consistently applying `maxPostponedStateSize`. Repeating or parallelizing these requests causes the Node.js process or hosting container to consume increasing memory. Once memory pressure exceeds available capacity or runtime limits, the application may slow down, restart, crash, return errors, or become unavailable to legitimate users.

How to fix it

Upgrade Next.js to version 16.1.7 or later. This version enforces postponed-body size limits consistently across all affected buffering paths and returns an error when limits are exceeded. If an immediate upgrade is not possible, block all requests from untrusted clients that contain the `next-resume` header; this header is not valid for direct client-supplied traffic. Enforce this control at the CDN, WAF, reverse proxy, ingress controller, or application middleware layer. Also consider limiting request body size, applying rate limits to POST traffic, enabling memory-based autoscaling/restart safeguards, and reviewing whether `experimental.ppr` or `cacheComponents` is required until patching is complete.

How to confirm the fix worked

Confirm that deployed applications use Next.js 16.1.7 or later by checking package manifests, lockfiles, build artifacts, container images, and runtime dependency inventories. Verify whether App Router Partial Prerendering is enabled through `experimental.ppr` or `cacheComponents` settings. Test edge controls by sending a benign request containing the `next-resume` header and confirming it is blocked or rejected before reaching the application. For patched applications, validate that oversized `next-resume` POST bodies are rejected and do not cause sustained memory growth. Monitor application memory, restarts, latency, and 5xx rates during validation to ensure the denial-of-service condition is no longer reproducible.

Typical attack path

1. Discover or select an internet-accessible Next.js application likely running an affected 16.x version.
2. Send HTTP POST requests to application endpoints with the `next-resume: 1` header.
3. Attach oversized request bodies designed to force server-side buffering.
4. Repeat requests concurrently or continuously to increase memory pressure.
5. Trigger degraded performance, process restarts, crashes, 5xx responses, or denial of service.

How to detect it

To determine whether exploitation was attempted or successful, review CDN, WAF, load balancer, reverse proxy, and application access logs for inbound requests containing the `next-resume` header, especially with value `1`. Focus on POST requests with unusually large request bodies, long request durations, repeated requests from the same IPs, spikes in 413/400/500/502/503/504 responses, and traffic bursts preceding memory exhaustion or service restarts. Correlate suspicious requests with infrastructure telemetry such as Node.js heap growth, container memory saturation, OOMKilled events, process exits, autoscaling events, pod restarts, and application error logs. In WAF or proxy logs, useful fields include request headers, method, URI, content-length, response status, upstream response time, user agent, source IP, and bytes received. There are no known unique malware artifacts for this denial-of-service issue; detection should be based on protocol indicators and resource-exhaustion symptoms.

• next-resume: 1
• next-resume
• HTTP header "next-resume"
• POST request with header next-resume
• Content-Length greater than normal baseline with header next-resume
• experimental.ppr
• cacheComponents
• JavaScript heap out of memory
• FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
• OOMKilled
• out of memory
• upstream prematurely closed connection
• HTTP 503 with next-resume request
• HTTP 502 with next-resume request
• HTTP 504 with next-resume request

What your security team should do

• Prioritize upgrading all affected Next.js deployments from versions 16.0.1 through 16.1.6 to 16.1.7 or later, especially internet-facing applications.
• Immediately add WAF, CDN, reverse proxy, or ingress rules to block untrusted requests containing the `next-resume` header where upgrade timelines are not immediate.
• Inventory applications using App Router with Partial Prerendering enabled through `experimental.ppr` or `cacheComponents`.
• Set conservative maximum request body sizes and rate limits for POST requests at the edge.
• Add monitoring alerts for abnormal memory growth, process restarts, container OOM kills, latency spikes, and elevated 5xx responses.
• Review web access logs for historical requests containing the `next-resume` header, especially POST requests with large request bodies or repeated requests from the same source.
• Because no public exploit maturity or KEV listing is indicated, treat this as a high-priority availability risk rather than confirmed active exploitation, unless local telemetry shows suspicious traffic.