CVE-2025-59472

What it actually does

This is a remotely reachable denial-of-service flaw in Next.js applications that use Partial Prerendering with minimal mode enabled. When `experimental.ppr: true` or `cacheComponents: true` is configured together with `NEXT_PRIVATE_MINIMAL_MODE=1`, the PPR resume endpoint accepts unauthenticated POST requests containing the `Next-Resume: 1` header and processes attacker-controlled resume/postponed-state data. Two memory-exhaustion paths are described: the server may buffer an entire POST body into memory with no effective size cap, and it may synchronously inflate compressed resume data without bounding the decompressed output size. Either path can force excessive heap allocation and terminate the Node.js process with a V8 out-of-memory failure. Confidentiality and integrity are not directly impacted, but application availability can be lost.

Why it matters to the business

Successful exploitation can crash affected Next.js server processes and interrupt customer-facing web applications, APIs, storefronts, dashboards, or internal portals built on affected configurations. The zipbomb-style variant is operationally important because a small request may bypass normal reverse-proxy request-size limits while still causing large memory allocation inside the application. The vulnerability is not currently listed in CISA KEV, has low EPSS, and no public exploit maturity is reported, but internet-facing applications with the vulnerable feature combination should still be prioritized because exploitation requires no authentication and can produce direct service outages.

How an attack unfolds

An attacker first identifies a Next.js application exposing the PPR resume behavior while running in minimal mode. They then send unauthenticated POST requests to a route handled by the PPR resume endpoint and include the `Next-Resume: 1` header. In the large-body variant, the request body is made large enough that the application buffers it into memory until the Node.js heap is exhausted. In the decompression variant, the attacker sends compressed resume data that is small on the wire but expands to a very large buffer when processed by `inflateSync()`. Because decompression happens inside the application without an output limit, upstream body-size controls may not prevent the memory spike. Once the heap limit is reached, V8 raises a fatal out-of-memory error and the Node.js process exits or is restarted by the process manager. Repeated requests can create a sustained availability incident.

How to fix it

Upgrade affected Next.js deployments to a fixed release. The advisory text recommends upgrading to Next.js `16.1.5` or `15.6.0-canary.61`; the provided source metadata also identifies upstream Git fix commit `c654bec6eb08382ed2ef47c90317039b6693f62a` for `vercel/next.js`. If Ubuntu `linux-xilinx-zynqmp` packages are in scope for separate asset tracking, update Ubuntu 22.04 LTS systems to `5.15.0-1060.64`, though that package appears unrelated to the described Next.js application-layer issue and should be validated against vendor advisories. If immediate upgrade is not possible, reduce exposure by disabling PPR/cache components where feasible, removing `NEXT_PRIVATE_MINIMAL_MODE=1` from affected deployments, enforcing strict request body limits at the application layer, rejecting or rate-limiting unauthenticated requests with `Next-Resume: 1`, bounding decompressed payload size, and ensuring supervisors restart crashed Node.js processes while rate controls prevent crash loops.

How to confirm the fix worked

Confirm whether applications are exposed by checking deployed Next.js versions and runtime configuration for `experimental.ppr: true` or `cacheComponents: true` combined with `NEXT_PRIVATE_MINIMAL_MODE=1`. Verify the deployed package version is fixed, or that the upstream patch containing commit `c654bec6eb08382ed2ef47c90317039b6693f62a` is present. Review application code, build artifacts, container images, and runtime environment variables rather than relying only on package inventory. Confirm mitigations by validating that unauthenticated requests with `Next-Resume: 1` are blocked, tightly size-limited, or handled by patched code. In a controlled non-production environment only, perform safe negative testing with small requests to verify the endpoint is not reachable and that oversized or compressed resume payloads are rejected before large memory allocation occurs. Monitor memory usage and process stability during validation.

Typical attack path

1. Discover or target an internet-facing Next.js application likely using Partial Prerendering or cache components.
2. Send unauthenticated POST requests containing the `Next-Resume: 1` header to application routes that trigger PPR resume processing.
3. Use either an oversized POST body or a small compressed payload that expands dramatically during server-side inflation.
4. Cause the Next.js/Node.js process to allocate excessive memory while buffering or decompressing the attacker-controlled state data.
5. Trigger a fatal V8 heap out-of-memory condition and crash the server process.
6. Repeat requests as processes restart to sustain denial of service.

How to detect it

To determine whether exploitation already occurred, review web access logs, CDN/WAF logs, reverse-proxy logs, application logs, container logs, process-manager logs, and host telemetry. Look for unauthenticated POST requests containing the `Next-Resume: 1` header, especially requests with unusually large bodies, compressed payload characteristics, high request rates from a small set of IPs, or requests immediately preceding Node.js restarts. In application and stderr logs, search for V8 fatal out-of-memory messages, heap-limit errors, `inflateSync` failures or unusually slow resume processing, and abrupt process exits. In container or orchestration telemetry, correlate OOMKilled events, restart count increases, memory spikes, and health-check failures with inbound POST traffic carrying `Next-Resume`. In infrastructure metrics, look for sharp RSS/heap growth followed by process termination, 502/503/504 spikes, or repeated cold starts. Because this is a denial-of-service issue, useful evidence is usually temporal correlation between suspicious requests and process crashes rather than persistent malware artifacts.

• Next-Resume: 1
• "Next-Resume"
• FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
• JavaScript heap out of memory
• Reached heap limit
• Allocation failed - JavaScript heap out of memory
• Ineffective mark-compacts near heap limit
• FatalProcessOutOfMemory
• OOMKilled
• exit code 134
• exit code 137
• SIGABRT
• POST

What your security team should do

• Inventory internet-facing and business-critical Next.js services and identify those using PPR, cache components, or minimal mode.
• Prioritize upgrade of affected services to Next.js `16.1.5` or `15.6.0-canary.61`, or to a build that includes upstream fix commit `c654bec6eb08382ed2ef47c90317039b6693f62a`.
• If upgrade cannot be completed quickly, disable PPR/cache components or unset `NEXT_PRIVATE_MINIMAL_MODE=1` for exposed deployments where operationally feasible.
• Add WAF, reverse-proxy, or application-layer controls to block, challenge, or rate-limit unauthenticated POST requests containing `Next-Resume: 1`, while recognizing that proxy body-size limits alone may not stop decompression-based attacks.
• Set explicit application-level maximums for request body size, compressed input size, and decompressed output size where custom handling is present.
• Increase monitoring for Node.js out-of-memory crashes, process restarts, elevated RSS/heap usage, and bursts of POST requests with the `Next-Resume` header.
• Review historical logs for signs of exploitation attempts, especially around unexplained availability incidents or Node.js crash loops.
• Validate any `linux-xilinx-zynqmp` findings separately with OS/package owners because the listed Ubuntu package metadata may not correspond to the described Next.js vulnerability.