GHSA-q4gf-8mx6-v5v3

What it actually does

This vulnerability allows a remote attacker to trigger a denial-of-service condition in affected Next.js applications that use Server Components. At a technical level, specially crafted or abusive HTTP requests to Server Component rendering paths can cause excessive server-side processing, resource consumption, or request handling saturation. The expected impact is loss of availability or degraded performance of the Next.js application; there is no indication from the provided advisory data that this flaw enables remote code execution, data theft, authentication bypass, or privilege escalation.

Why it matters to the business

A successful attack can make affected Next.js web applications slow, intermittently unavailable, or fully unreachable, disrupting customer-facing services, internal portals, APIs backed by the application, and revenue-generating web workflows. Because Next.js is widely used in production web stacks and the issue is remotely reachable over HTTP, organizations running vulnerable versions should treat this as an availability risk even though 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 provided data.

How an attack unfolds

An attacker identifies a publicly reachable Next.js application running an affected version of the npm package and determines that Server Components are in use. The attacker then sends crafted or high-volume HTTP requests targeting routes or requests that cause Server Component rendering behavior. Vulnerable versions may consume disproportionate CPU, memory, worker capacity, or event-loop time while processing those requests. By repeating the requests or distributing them across clients, the attacker can exhaust application capacity, leading to slow responses, elevated error rates, timeouts, container or process restarts, autoscaling churn, or complete service unavailability. Since the known impact is denial of service, exploitation does not require the attacker to obtain credentials or execute code; the main attacker objective is service disruption.

How to fix it

Upgrade the affected Next.js package to a fixed version. For the npm package `next`, upgrade to `15.5.15` or later if using the 15.x release line, or to `16.2.3` or later if using the 16.x release line. After upgrading, rebuild and redeploy the application so the patched framework code is actually running in production. If immediate upgrade is not possible, reduce exposure by placing the application behind a CDN, WAF, reverse proxy, or load balancer with request rate limits, concurrency limits, request body/header size limits, bot controls, and per-IP throttling for expensive routes. Consider temporarily limiting access to non-public Server Component-heavy routes, increasing server capacity, and adding circuit breakers or timeouts for expensive rendering paths until patching is complete.

How to confirm the fix worked

Confirm remediation by checking the resolved version of the `next` package in package manager metadata and lockfiles, such as `package-lock.json`, `npm ls next`, `pnpm list next`, or `yarn why next`. The running application should be rebuilt from the patched dependency and redeployed; verifying only `package.json` is insufficient if the lockfile or deployed artifact still contains a vulnerable version. Confirm that production images, serverless bundles, and build artifacts no longer include affected Next.js versions. Operationally, validate that rate limiting and timeout controls are active at the edge or reverse proxy, and perform safe internal load testing against representative Server Component routes to confirm the application remains stable under expected request patterns.

Typical attack path

1. Identify a public web application or endpoint built with Next.js.
2. Fingerprint the application or infer Next.js usage from headers, asset paths, JavaScript bundles, or framework behavior.
3. Determine whether Server Components or App Router-style routes are exposed.
4. Send crafted HTTP requests that trigger vulnerable Server Component handling, or send repeated requests that amplify resource consumption.
5. Monitor response latency, timeout behavior, HTTP 5xx rates, and server availability to tune the request pattern.
6. Sustain or distribute the request volume until the application becomes degraded or unavailable.

How to detect it

To assess whether this was already exploited, review web server, CDN, WAF, reverse proxy, application, container, and infrastructure monitoring logs for unexplained traffic bursts to Next.js routes that use Server Components, especially requests containing Server Component-related headers or query parameters. Look for correlated increases in response latency, request timeouts, HTTP 5xx responses, upstream connection failures, Node.js process restarts, out-of-memory kills, CPU saturation, memory exhaustion, event-loop lag, and autoscaling events. Compare request volume by source IP, ASN, user agent, URI, and route before, during, and after any outage or degradation window. Because no specific exploit payload or public IOC is provided, detection should focus on behavioral indicators: repeated requests to expensive rendering paths, abnormal concentrations of `RSC` or router-state requests, and resource exhaustion temporally aligned with those requests. Treat the listed network strings as triage pivots, not proof of compromise, because they may also appear in legitimate Next.js Server Component traffic.

• RSC: 1
• Next-Router-State-Tree
• Next-Router-Prefetch
• Next-Url
• _rsc=
• text/x-component
• /_next/static/
• /_next/server/
• JavaScript heap out of memory
• Allocation failed - JavaScript heap out of memory
• FATAL ERROR: Ineffective mark-compacts near heap limit
• ENOMEM
• EADDRINUSE
• upstream timed out
• upstream prematurely closed connection
• HTTP 503
• HTTP 504
• SIGKILL
• OOMKilled

What your security team should do

• Prioritize upgrading all affected Next.js applications to `next` version `15.5.15` or later, or `16.2.3` or later, depending on the release line in use.
• Inventory externally exposed Next.js applications and determine which ones use Server Components or App Router functionality.
• Search SBOMs, lockfiles, container images, and CI/CD artifacts for vulnerable `next` package versions rather than relying only on top-level dependency declarations.
• Apply rate limiting, request throttling, CDN caching, WAF protections, and resource limits to public routes that trigger server-side rendering or Server Component processing.
• Monitor web traffic for spikes in Server Component-related requests, elevated latency, HTTP 499/500/502/503/504 responses, process restarts, memory pressure, and CPU saturation.
• Review autoscaling and resource exhaustion alerts to ensure availability-impacting attacks are detected quickly.
• Because the issue has been public for 121 days, treat unpatched internet-facing deployments as exposed even though the provided data does not show KEV listing, ransomware use, or mature public exploit availability.