CVE-2025-59472 in next.js
Summary
by MITRE • 01/27/2026
A denial of service vulnerability exists in Next.js versions with Partial Prerendering (PPR) enabled when running in minimal mode. The PPR resume endpoint accepts unauthenticated POST requests with the `Next-Resume: 1` header and processes attacker-controlled postponed state data. Two closely related vulnerabilities allow an attacker to crash the server process through memory exhaustion:
1. **Unbounded request body buffering**: The server buffers the entire POST request body into memory using `Buffer.concat()` without enforcing any size limit, allowing arbitrarily large payloads to exhaust available memory.
2. **Unbounded decompression (zipbomb)**: The resume data cache is decompressed using `inflateSync()` without limiting the decompressed output size. A small compressed payload can expand to hundreds of megabytes or gigabytes, causing memory exhaustion.
Both attack vectors result in a fatal V8 out-of-memory error (`FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory`) causing the Node.js process to terminate. The zipbomb variant is particularly dangerous as it can bypass reverse proxy request size limits while still causing large memory allocation on the server.
To be affected you must have an application running with `experimental.ppr: true` or `cacheComponents: true` configured along with the NEXT_PRIVATE_MINIMAL_MODE=1 environment variable.
Strongly consider upgrading to 15.6.0-canary.61 or 16.1.5 to reduce risk and prevent availability issues in Next applications.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 02/26/2026
The vulnerability described in CVE-2025-59472 represents a critical denial of service threat targeting Next.js applications utilizing Partial Prerendering (PPR) in minimal mode. This flaw exists within the resume endpoint functionality that handles POST requests containing the `Next-Resume: 1` header, creating a pathway for attackers to deliberately crash server processes through memory exhaustion attacks. The vulnerability specifically affects applications configured with `experimental.ppr: true` or `cacheComponents: true` alongside the `NEXT_PRIVATE_MINIMAL_MODE=1` environment variable, making it particularly relevant to developers who have implemented these performance optimization features in their applications.
The technical implementation of this vulnerability manifests through two distinct but interconnected attack vectors that exploit memory handling weaknesses in the Next.js server-side processing pipeline. The first vector involves unbounded request body buffering where the server employs `Buffer.concat()` to accumulate entire POST request bodies in memory without implementing any size constraints. This allows malicious actors to submit arbitrarily large payloads that consume all available memory resources, leading to immediate system crashes. The second and more sophisticated vector involves unbounded decompression through the `inflateSync()` function used for processing resume data cache decompression. This creates a zipbomb scenario where compressed payloads can expand to massive uncompressed sizes, effectively bypassing reverse proxy size limitations while still causing catastrophic memory allocation failures on the target server.
Both attack vectors converge on the same fatal outcome - a V8 JavaScript heap out-of-memory error that terminates the Node.js process entirely. The vulnerability's design allows for execution without authentication requirements, making it particularly dangerous as any attacker with access to the application endpoint can trigger the service disruption. The memory exhaustion occurs at the JavaScript heap level, producing the specific error message "FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory" which indicates the underlying V8 engine's inability to allocate additional memory for the process. This type of vulnerability aligns with CWE-400 (Uncontrolled Resource Consumption) and CWE-129 (Improper Validation of Array Index) categories, representing a classic example of resource exhaustion attacks that can severely impact application availability and system stability.
The operational impact of this vulnerability extends beyond simple service disruption to encompass broader security implications for applications running in production environments. Organizations relying on Next.js applications with PPR enabled in minimal mode face significant risk of denial of service attacks that can render their services completely unavailable to legitimate users. The zipbomb variant particularly presents challenges for network security monitoring and protection, as it can bypass traditional reverse proxy protections while still causing the same devastating memory exhaustion effects. This vulnerability directly maps to ATT&CK technique T1499.004 (Endpoint Denial of Service) and demonstrates how seemingly legitimate application features can become attack vectors when proper input validation and resource management controls are absent. The combination of these two attack vectors creates a particularly dangerous scenario where even small malicious requests can cause substantial system-wide failures, making this vulnerability a high-priority concern for security teams managing Next.js applications in production environments.
The recommended mitigation strategy involves upgrading to specific Next.js versions that contain patches addressing both memory buffering and decompression limitations. Version 15.6.0-canary.61 and 16.1.5 include critical fixes that implement proper size limits for request body processing and decompression operations, effectively closing the memory exhaustion pathways. Organizations should prioritize this upgrade path while also considering implementing additional monitoring and rate limiting controls around the affected resume endpoint. The vulnerability serves as a reminder of the importance of proper resource management in server-side applications and the need for comprehensive input validation even in features designed for performance optimization. Security teams should also conduct thorough testing to ensure that the patched versions do not introduce regressions in application functionality while verifying that the memory consumption limits are properly enforced across all deployment scenarios.