GHSA-mwv6-3258-q52c

What it actually does

This vulnerability affects the Next.js npm package and can allow a remote attacker to trigger excessive server-side resource consumption when Server Components are processed. At a technical level, specially crafted requests to routes using Next.js Server Components may cause disproportionate CPU, memory, event-loop, or rendering workload, resulting in degraded responsiveness or denial of service for the affected Next.js application. The issue is classified as denial of service and does not, by itself, indicate code execution or data disclosure.

Why it matters to the business

Successful exploitation can make affected web applications slow, unstable, or unavailable, disrupting customer-facing services, internal portals, APIs, and revenue-generating workflows that depend on Next.js. Because Next.js is widely used in modern web stacks, exposure may exist in multiple applications through direct or transitive use of the next npm package. The vulnerability has a high severity score, but it is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has no reported mature public exploit in the supplied data; remediation should still be prioritized for internet-facing or high-traffic applications.

How an attack unfolds

An attacker first identifies a publicly reachable Next.js application, especially one exposing routes that use Server Components. They then send crafted HTTP requests designed to exercise the vulnerable Server Components behavior and force the server to perform expensive rendering or processing work. By repeating these requests or distributing them across clients, the attacker can exhaust application resources, saturate worker capacity, increase response latency, and eventually cause timeouts or service unavailability. Exploitation does not require compromising credentials if the affected route is publicly accessible, although authenticated routes may also be targeted if the attacker has access.

How to fix it

Upgrade the next npm package to a fixed version appropriate for the application’s release line: 14.2.34 or later for 14.x, 15.0.6 or later for 15.0.x, 15.1.10 or later for 15.1.x, 15.2.7 or later for 15.2.x, 15.3.7 or later for 15.3.x, 15.4.9 or later for 15.4.x, 15.5.8 or later for 15.5.x, 15.6.0-canary.59 or later for 15.6 canary, 16.0.9 or later for 16.0.x, or 16.1.0-canary.17 or later for 16.1 canary. Regenerate lockfiles, rebuild containers or deployment artifacts, and redeploy all affected applications. If immediate upgrade is not possible, reduce exposure by applying rate limits, request timeouts, CDN/WAF protections, bot mitigation, concurrency limits, and resource isolation for Next.js workloads, especially on routes using Server Components.

How to confirm the fix worked

Confirm the deployed artifact is running a fixed next version by checking package-lock.json, yarn.lock, pnpm-lock.yaml, npm list next, yarn why next, pnpm why next, container SBOMs, and runtime build metadata. Verify that no deployed application still resolves to a vulnerable next package version. After patching, perform controlled load and regression testing against Server Component routes to confirm normal resource usage and absence of abnormal latency or crashes. Validate that rate limits, request size limits, request timeouts, autoscaling, and health checks are functioning as expected. Software composition analysis and CI dependency scanning should be updated to flag vulnerable next versions.

Typical attack path

1. Identify an application built with the affected next npm package.
2. Find reachable routes that invoke Next.js Server Components or server-side rendering behavior.
3. Send crafted HTTP requests that trigger the vulnerable Server Components processing path.
4. Repeat or parallelize requests to amplify CPU, memory, event-loop, or rendering workload.
5. Cause degraded application performance, elevated error rates, request timeouts, process restarts, or full service outage.

How to detect it

To assess prior exploitation, review CDN, WAF, load balancer, reverse proxy, and application access logs for sudden bursts of repeated requests to Next.js routes, especially routes associated with Server Components or React Server Component payloads. Look for abnormal increases in HTTP 500, 502, 503, 504, 408, and 429 responses; elevated request latency; repeated client disconnects; and concentrated traffic from single IPs, ASNs, user agents, or distributed bot-like sources. Examine application and process telemetry for correlated CPU spikes, memory exhaustion, Node.js event-loop lag, out-of-memory kills, container restarts, autoscaling events, and health-check failures. Review Next.js and Node.js logs for rendering errors, request aborts, timeouts, and crashes occurring at the same time as suspicious request bursts. Because the supplied intelligence does not provide a public exploit signature, detection should focus on behavioral denial-of-service patterns against Next.js Server Component endpoints rather than a single definitive payload string.

• HTTP requests containing RSC: 1
• HTTP requests containing Next-Router-State-Tree
• HTTP query parameter _rsc=
• HTTP response status 503 spike on Next.js routes
• HTTP response status 504 spike on Next.js routes
• Error: Request aborted
• Error: aborted
• JavaScript heap out of memory
• FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
• Container OOMKilled
• Node.js process restart loop
• next-server
• node server.js

What your security team should do

• Inventory all applications and container images using the next npm package, including transitive or bundled dependencies.
• Prioritize upgrades for internet-facing, unauthenticated, business-critical, and high-traffic Next.js applications.
• Upgrade to the fixed version matching the deployed release line and redeploy from clean builds with updated lockfiles.
• Add or tune CDN, WAF, reverse proxy, and application-layer rate limiting for routes that invoke Server Components.
• Monitor web, CDN, reverse proxy, application, and infrastructure telemetry for spikes in repeated requests, high latency, 5xx errors, process restarts, memory pressure, or CPU saturation.
• Run dependency scanning in CI/CD and block releases that include vulnerable next versions.
• If exploitation is suspected, preserve web access logs, application logs, container logs, process metrics, and autoscaling or orchestrator events for incident review.