Next.js Server Crash Vulnerability via Oversized Requests (CVE-2025-59472)

Vulnerability Explanation

The PPR resume endpoint in Next.js minimal mode accepts unauthenticated POST requests bearing the 'Next-Resume: 1' header and processes attacker-controlled postponed state data. Two distinct attack vectors both lead to Node.js process termination via heap exhaustion: (1) Unbounded request body buffering — the server accumulates the entire POST body using Buffer.concat() with no size cap, so an arbitrarily large payload can exhaust available RAM; (2) Zipbomb decompression — the resume data cache is decompressed with inflateSync() without an output size limit, meaning a small compressed payload can expand to hundreds of megabytes or gigabytes in memory. Both vectors produce a fatal V8 OOM error ('FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory'), terminating the Node.js process and taking the application offline. The zipbomb variant is particularly effective because it can bypass reverse-proxy request size limits while still triggering large server-side allocations.

Root Cause

The PPR resume endpoint was implemented without input validation or resource consumption controls. Specifically, no maximum request body size is enforced before buffering, and no decompressed output size limit is applied before processing. This is a classic CWE-400 (Uncontrolled Resource Consumption) pattern — the server unconditionally trusts the size of attacker-supplied data.

Technical Impact

Complete denial of service. An unauthenticated remote attacker can crash the Node.js server process with a single HTTP request, causing full application unavailability. No data exfiltration, privilege escalation, or code execution is possible. Impact is limited to availability.

Severity Justification

CVSS 5.9 (Moderate) per the official GitHub Advisory and Vercel changelog. Network-based, no authentication required, no user interaction needed, but exploitability is gated behind a specific non-default configuration (PPR + minimal mode). Impact is limited to availability — no confidentiality or integrity impact.

Affected Components

• next >= 15.0.0-canary.0, < 15.6.0-canary.61
• next >= 16.0.0-beta.0, < 16.1.5

Remediation Steps

1. Verify whether you are affected: check next.config.js for 'experimental.ppr: true' or 'cacheComponents: true', AND confirm the NEXT_PRIVATE_MINIMAL_MODE=1 environment variable is set. If either condition is absent, you are not affected.
2. Upgrade the next package to the patched version for your release line: 'npm install next@15.6.0-canary.61' (v15 line) or 'npm install next@16.1.5' (v16 line). Commit the updated package-lock.json.
3. If an immediate upgrade is not possible, disable PPR as a temporary workaround by setting 'experimental.ppr: false' in next.config.js, or remove the NEXT_PRIVATE_MINIMAL_MODE=1 environment variable.
4. As a defense-in-depth measure, enforce a request body size limit at your reverse proxy (e.g., Nginx 'client_max_body_size') to reduce the unbounded buffering attack surface, noting this does not fully mitigate the zipbomb vector.
5. After upgrading, redeploy and verify the running version matches the patched release.

Verification Steps

1. Run 'npm list next' or 'cat node_modules/next/package.json | grep version' to confirm the installed version is at or above the patched release.
2. Check your next.config.js to confirm 'experimental.ppr' is either absent or set to false, OR that NEXT_PRIVATE_MINIMAL_MODE is not set in your environment.
3. Optionally, send a test POST request with the 'Next-Resume: 1' header to a PPR route and confirm the server returns an error response rather than crashing (do this only in a staging environment).

Code Examples (javascript)

// next.config.js — affected configuration
module.exports = {
  experimental: {
    ppr: true,  // PPR enabled
  },
};
// AND environment variable set:
// NEXT_PRIVATE_MINIMAL_MODE=1

// Option 1: Upgrade next to a patched version
// package.json
{
  "dependencies": {
    "next": "^15.6.0-canary.61"  // or "^16.1.5"
  }
}

// Option 2 (temporary workaround): Disable PPR
// next.config.js
module.exports = {
  experimental: {
    ppr: false,  // PPR disabled
  },
};

// Option 3 (defense-in-depth): Nginx body size limit
// nginx.conf
server {
  client_max_body_size 10m;  // Restrict request body size
}

Best Practices

• Never expose internal framework endpoints (such as PPR resume endpoints) directly to the public internet without authentication or a WAF rule.
• Enforce request body size limits at the reverse proxy layer as a defense-in-depth control, independent of application-level limits.
• Pin or lock your Next.js version in package-lock.json and use automated dependency scanning (e.g., Dependabot, Renovate) to receive timely alerts for new CVEs.
• When using experimental framework features in production, monitor the framework's security advisories closely, as experimental APIs may have less hardening than stable ones.

References

• github.com/advisories/GHSA-5f7q-jpqc-wp7h
• vercel.com/changelog/summaries-of-cve-2025-59471-and-cve-2025-59472
• nvd.nist.gov/vuln/detail/CVE-2025-59472