GHSA-h25m-26qc-wcjf

What it actually does

The vulnerability affects the Next.js npm package when React Server Components are used in an insecure configuration. A crafted HTTP request can trigger unsafe or excessive deserialization behavior in the server-side React/Next.js request handling path, causing the application process to consume excessive CPU, memory, or event-loop time. The primary technical outcome is denial of service: affected Next.js servers may become slow, unresponsive, crash, or repeatedly restart under malicious request load. There is no indication from the provided data that this issue enables code execution, authentication bypass, or data disclosure.

Why it matters to the business

A successful attack can make customer-facing or internal Next.js applications unavailable, causing service disruption, failed transactions, degraded user experience, alert fatigue, and increased infrastructure costs from autoscaling or repeated process restarts. The CVSS score of 7.5 indicates high severity because exploitation can be performed remotely against exposed web applications, but the absence of known exploitation, KEV listing, ransomware association, or mature public exploit lowers immediate threat urgency compared with actively exploited vulnerabilities. Because Next.js is widely used for production web applications, organizations should still prioritize upgrades during the next urgent patch cycle, especially for internet-facing services using React Server Components.

How an attack unfolds

An attacker first identifies a Next.js application that exposes routes using React Server Components or related server-side component request handling. They then send specially crafted HTTP requests that abuse the vulnerable deserialization path. The malformed or resource-intensive payload causes the server to spend disproportionate resources processing the request, potentially blocking the Node.js event loop, increasing memory usage, or causing worker/process crashes. By repeating the request, or sending it concurrently from one or more sources, the attacker can sustain application degradation or outage. Because this is a denial-of-service issue, exploitation may leave limited host-level artifacts beyond abnormal request patterns, elevated resource utilization, application errors, and restart events.

How to fix it

Upgrade the Next.js npm package to a fixed version appropriate for the release line in use. Fixed versions are: 15.0.8, 15.1.12, 15.2.9, 15.3.9, 15.4.11, 15.5.10, 15.6.0-canary.61, 16.0.11, or 16.1.5. Prefer upgrading to the latest stable supported Next.js release compatible with the application. After upgrading, rebuild and redeploy the application so the patched server runtime is actually in use. If immediate upgrade is not possible, reduce exposure by placing the application behind rate limiting, request body size limits, WAF rules for malformed RSC-related requests, bot mitigation, and autoscaling safeguards. Review use of React Server Components and avoid insecure or experimental patterns that accept untrusted serialized component data without framework-supported validation.

How to confirm the fix worked

Confirm the deployed dependency version with package manager tooling such as `npm ls next`, `pnpm why next`, `yarn why next`, lockfile review, container image SBOMs, and deployed artifact inspection. The running application should use one of the fixed Next.js versions: 15.0.8, 15.1.12, 15.2.9, 15.3.9, 15.4.11, 15.5.10, 15.6.0-canary.61, 16.0.11, or 16.1.5, or a later non-vulnerable release. Validate that CI/CD builds consume the patched lockfile and that old containers, serverless functions, edge deployments, and cached build artifacts have been replaced. Perform controlled negative testing against non-production environments to ensure malformed RSC-style requests are rejected or handled without abnormal CPU, memory, latency, or process restarts. Monitor production after deployment for reduced 5xx responses, fewer process crashes, stable memory usage, and normal request latency.

Typical attack path

1. Identify an internet-accessible application built with an affected version of the Next.js npm package.
2. Determine whether the application exposes React Server Components, server actions, or RSC-related request handling paths.
3. Send crafted HTTP requests designed to trigger vulnerable deserialization behavior.
4. Repeat or parallelize the requests to amplify CPU, memory, or event-loop exhaustion.
5. Cause the Next.js application process or hosting platform to slow down, return errors, crash, restart, or become unavailable.

How to detect it

Look for signs of attempted or successful denial-of-service against Next.js applications. Useful sources include CDN logs, load balancer logs, WAF logs, reverse proxy logs, application access logs, Next.js application logs, Node.js process logs, container orchestration events, serverless platform logs, APM traces, and infrastructure metrics. Investigate short bursts or sustained waves of requests with RSC-related headers, query parameters, or content types, especially when correlated with increased response latency, HTTP 500/502/503/504 responses, memory growth, high CPU, Node.js event-loop lag, out-of-memory errors, process exits, container restarts, or autoscaling events. Since this is a DoS vulnerability, evidence may be volumetric and behavioral rather than a persistent file or malware artifact. If named threat actors are not known and exploit maturity is listed as none, prioritize correlation of suspicious HTTP patterns with application instability rather than assuming compromise. Preserve request samples, source IPs, user agents, timestamps, response codes, and process crash logs for forensic review.

• RSC: 1
• Next-Action:
• Content-Type: text/x-component
• Accept: text/x-component
• ?_rsc=
• Error: JavaScript heap out of memory
• FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
• ENOMEM
• ECONNRESET
• HTTP 500
• HTTP 502
• HTTP 503
• HTTP 504
• SIGTERM
• SIGKILL
• OOMKilled
• CrashLoopBackOff
• npm ls next

What your security team should do

• Inventory all applications and container images using the Next.js npm package, prioritizing internet-facing services and applications using React Server Components.
• Upgrade affected applications to the relevant fixed Next.js version or later, and ensure redeployment replaces all vulnerable runtime artifacts.
• Add temporary compensating controls until patching is complete: rate limiting, request body size limits, WAF filtering for anomalous RSC-related traffic, and alerting on request spikes.
• Review dependency lockfiles and SBOMs in CI/CD to prevent reintroduction of vulnerable Next.js versions.
• Create detection logic for bursts of RSC-related requests followed by elevated 5xx responses, high Node.js CPU or memory usage, event-loop lag, process crashes, or platform restarts.
• Because there is no known KEV listing or mature exploit reported in the provided data, treat this as high-priority hardening rather than an active emergency unless local telemetry shows exploitation-like traffic or availability impact.