GHSA-8h8q-6873-q5fj

What it actually does

This vulnerability affects Next.js applications using Server Components and can allow a remote attacker to trigger excessive server-side resource consumption. By sending crafted requests that exercise vulnerable Server Component handling paths, an attacker may cause high CPU, memory pressure, blocked request workers, or degraded rendering performance, resulting in denial of service. The issue is product-level and affects the `next` npm package until the fixed releases.

Why it matters to the business

Successful exploitation can make public-facing web applications slow, intermittently unavailable, or fully unreachable, disrupting customer access, revenue-generating workflows, internal portals, and API-backed user experiences. Because Next.js is widely used for production web front ends, even a relatively simple denial-of-service condition can create operational incidents, elevated infrastructure costs from autoscaling, and customer trust impact. Although there is no known KEV listing or confirmed exploit maturity in the provided data, the vulnerability has been public for 91 days, so exposed applications should be upgraded during the next urgent maintenance window.

How an attack unfolds

An attacker first identifies a Next.js deployment that uses affected versions of the `next` package and exposes routes backed by Server Components. The attacker then sends crafted HTTP requests designed to trigger the vulnerable Server Component processing behavior. Repeated or concurrent requests can force the application server to spend disproportionate resources rendering, resolving, or serializing component responses. If the application has limited worker capacity, memory headroom, or insufficient rate limiting, legitimate users begin seeing slow responses, timeouts, or service errors. The attacker does not need authentication unless the vulnerable routes are access-controlled, and impact may be amplified through automation or distributed request sources.

How to fix it

Upgrade the `next` npm package to a fixed version. For the 15.x line, upgrade to `next` 15.5.16 or later. For the 16.x line, upgrade to `next` 16.2.5 or later. Rebuild and redeploy affected applications after updating dependencies, and ensure lockfiles are refreshed so the fixed version is actually installed in production artifacts. If immediate upgrade is not possible, reduce exposure by placing affected applications behind a CDN or reverse proxy with aggressive request rate limits, concurrency limits, request body/header size limits, bot filtering, and caching where safe. Monitor autoscaling and resource ceilings to prevent cascading infrastructure failure, but treat these as temporary mitigations rather than a substitute for upgrading.

How to confirm the fix worked

Confirm the deployed application is using a fixed `next` package version by inspecting `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`, container image SBOMs, build logs, or runtime dependency inventories. Validate that production deployments have been rebuilt after the dependency update and are not still running older image layers or serverless bundles. Run `npm ls next`, `yarn why next`, or `pnpm why next` in source and build environments to identify all affected copies. Confirm fixed versions are at least `15.5.16` for the 15.x branch or `16.2.5` for the 16.x branch. Operationally, verify that request latency, CPU, memory use, worker saturation, and HTTP 5xx rates remain stable under controlled load testing of Server Component routes.

Typical attack path

1. Identify a web application built with Next.js and determine whether it exposes Server Component routes or application router functionality.
2. Probe application routes for responses and behaviors consistent with affected Next.js Server Component handling.
3. Send crafted HTTP requests that trigger excessive server-side processing in the vulnerable component rendering path.
4. Automate repeated or concurrent requests to increase CPU, memory, or worker exhaustion.
5. Sustain the traffic until legitimate users experience latency, timeouts, HTTP 5xx responses, or application unavailability.

How to detect it

To determine whether exploitation has already occurred, review web server, CDN, WAF, reverse proxy, application, and infrastructure telemetry for denial-of-service patterns targeting dynamic Next.js routes or Server Component endpoints. Look for bursts of repeated requests from one or many source IPs, abnormal request rates to the same small set of routes, spikes in response time, elevated HTTP 5xx/timeout responses, increased origin fetches bypassing cache, and resource exhaustion on application hosts or serverless functions. Correlate traffic anomalies with CPU saturation, memory pressure, Node.js process restarts, container OOM kills, event-loop delay, autoscaling events, and elevated render duration metrics. Because no specific public exploit indicators or threat actors were provided, detection should focus on behavioral signs of resource-exhaustion attempts rather than a single known payload. Pay particular attention to activity from the 91 days since publication onward.

• HTTP 503
• HTTP 504
• HTTP 502
• upstream timed out
• connect() failed
• worker process exited
• JavaScript heap out of memory
• ENOMEM
• FATAL ERROR: Reached heap limit
• Killed process
• OOMKilled
• next-server
• /_next/
• RSC
• Next-Router-State-Tree
• Next-Router-Prefetch
• text/x-component

What your security team should do

• Inventory all applications and services using the `next` npm package, including containerized, serverless, and statically hosted deployments with server-side rendering components.
• Prioritize upgrades for internet-facing Next.js applications, authentication portals, commerce flows, and applications with limited horizontal scaling capacity.
• Upgrade to `next` 15.5.16 or later for 15.x deployments, or `next` 16.2.5 or later for 16.x deployments, then rebuild and redeploy production artifacts.
• Add or tune CDN, WAF, reverse proxy, and application-layer rate limits for Server Component and dynamic rendering routes.
• Review observability dashboards for unusual increases in request volume, render latency, CPU, memory, event-loop delay, worker restarts, HTTP 499/502/503/504 responses, or autoscaling events since publication.
• Ensure dependency scanning and CI policies fail builds that include vulnerable `next` versions.
• Prepare an incident response playbook for application-layer denial-of-service events, including traffic shaping, route-specific throttling, and emergency rollback or scale-out procedures.