CVE-2026-44579

What it actually does

CVE-2026-44579 is a network-exploitable denial-of-service vulnerability in Next.js applications using Partial Prerendering through the Cache Components feature. In vulnerable versions before 15.5.16 and 16.2.5, specially crafted POST requests to a server action can trigger a request-body handling deadlock. The affected server leaves HTTP connections open for an extended period instead of completing or closing them, consuming sockets, file descriptors, worker capacity, and related application/runtime resources. Successful exploitation does not require authentication or user interaction and primarily impacts availability rather than confidentiality or integrity.

Why it matters to the business

Exploitation can make affected web applications slow or unavailable to legitimate users by exhausting server capacity with relatively low-effort remote traffic. For customer-facing sites, this can cause outages, failed transactions, degraded user experience, increased infrastructure costs from autoscaling, and operational burden for engineering and incident response teams. The issue has a high availability impact, but current public signals indicate low EPSS probability, no CISA KEV listing, no known ransomware association, and no stated mature public exploit; however, the vulnerability has been public for 88 days, so exposed vulnerable applications should still be upgraded promptly.

How an attack unfolds

An attacker first identifies a Next.js application running an affected version and using the vulnerable Partial Prerendering and Cache Components configuration with server actions reachable over HTTP. The attacker then sends crafted POST requests to a server action endpoint in a way that triggers the flawed request-body handling path. Instead of completing normally, the application can enter a deadlocked handling state and keep the underlying connection open for an extended period. By repeating this with many concurrent or sustained requests, the attacker consumes available file descriptors, sockets, worker slots, and application capacity. Once those resources are depleted, legitimate users experience timeouts, connection failures, or severe latency until the connections are cleared, the service is restarted, traffic is filtered, or the application is patched.

How to fix it

Upgrade Next.js to a fixed release: 15.5.16 or later for the 15.x line, or 16.2.5 or later for the 16.x line. If exact dependency constraints are managed through package manifests or lockfiles, update both the declared Next.js dependency and the resolved lockfile version, then rebuild and redeploy the application. If immediate upgrade is not possible, reduce exposure by disabling or avoiding the affected Partial Prerendering through Cache Components configuration where feasible, restricting access to affected server action routes, enforcing request body size limits, applying aggressive request and upstream timeouts, limiting concurrent connections per source, and using WAF/rate-limiting controls for abnormal POST floods. Also review reverse proxy, load balancer, Node.js runtime, and container limits for sane connection, header, body, and idle timeout settings so dead connections cannot accumulate indefinitely.

How to confirm the fix worked

Confirm the deployed application resolves Next.js to version 15.5.16 or later, or 16.2.5 or later, using package manager output, lockfile inspection, build artifacts, software composition analysis, or container image scanning. Verify that production deployments were rebuilt after the dependency update rather than only changing source control. Confirm whether Partial Prerendering and Cache Components are enabled and whether server action POST endpoints are externally reachable. Perform controlled testing in a non-production or isolated environment by sending malformed, partial, or slow POST requests to relevant server action endpoints and verifying that requests are rejected, completed, or timed out quickly without accumulating open file descriptors or long-lived connections. Monitor during validation for stable file descriptor counts, connection counts, request worker utilization, event loop latency, and absence of sustained 5xx or timeout spikes.

Typical attack path

1. Fingerprint the target as a Next.js application and infer or discover server action endpoints that accept POST requests.
2. Confirm the application is potentially running an affected release before 15.5.16 or 16.2.5 and uses Partial Prerendering with Cache Components.
3. Send crafted POST requests to a vulnerable server action endpoint that exercise the flawed request-body handling behavior.
4. Keep multiple requests active or repeat them at scale to cause long-lived open connections.
5. Exhaust server resources such as file descriptors, sockets, request workers, or reverse-proxy upstream connection pools.
6. Cause legitimate traffic to fail with timeouts, 5xx errors, refused connections, or elevated latency.

How to detect it

To determine whether exploitation has already occurred, review web server, CDN, WAF, load balancer, reverse proxy, and application logs for bursts of POST requests to Next.js server action routes, especially requests with unusually long durations, incomplete bodies, client disconnects, repeated timeouts, or responses ending in 499, 502, 503, or 504. Correlate these with infrastructure telemetry showing increased open TCP connections, high file descriptor usage, saturated Node.js workers, elevated event loop lag, increased upstream connection pool usage, memory growth, pod/container restarts, or autoscaling events. Look for repeated POST requests from the same source IPs, autonomous systems, cloud providers, or rotating sources with low response byte counts and long request times. In Node.js and application logs, investigate errors related to aborted requests, request body parsing, server action handling, socket hangups, EMFILE conditions, or upstream timeout exhaustion. Because this is a denial-of-service issue, strong evidence is usually behavioral rather than a durable host artifact: the key signal is abnormal long-lived POST concurrency to server action endpoints immediately preceding or during service degradation.

• POST /_actions
• POST /_next
• Next-Action
• next-action
• multipart/form-data
• application/x-www-form-urlencoded
• request aborted
• aborted request
• socket hang up
• ECONNRESET
• ETIMEDOUT
• upstream timed out
• upstream prematurely closed connection
• client prematurely closed connection
• too many open files
• EMFILE
• HTTP 499
• HTTP 502
• HTTP 503
• HTTP 504

What your security team should do

• Inventory internet-facing and internal Next.js applications and identify those using versions before 15.5.16 or 16.2.5.
• Prioritize remediation for externally exposed applications that use Partial Prerendering, Cache Components, and server actions accepting POST requests.
• Upgrade affected applications to Next.js 15.5.16 or 16.2.5 or later, rebuild artifacts, redeploy, and verify the runtime version.
• Apply compensating controls while upgrades are pending: rate limiting, per-IP connection limits, request body limits, upstream timeouts, and WAF rules for abnormal POST concurrency.
• Review load balancer, CDN, reverse proxy, Node.js, and container limits to prevent long-lived request buildup from exhausting file descriptors or workers.
• Create monitoring alerts for spikes in long-lived POST requests, open connections, file descriptor usage, 499/502/503/504 responses, request timeouts, and event loop lag.
• Search historical logs for signs of attempted exploitation since publication, especially sustained POST traffic to server action endpoints followed by availability degradation.
• Retest after patching to ensure crafted or slow POST requests no longer create persistent connections or resource exhaustion conditions.