CVE-2026-44576

What it actually does

Next.js versions 14.2.0 through versions before 15.5.16 and 16.2.5 can mishandle React Server Components responses when an application sits behind a shared cache that does not correctly separate response variants. Under the affected conditions, an unauthenticated remote attacker can influence cache keys or response negotiation so an RSC payload is cached for the original page URL. Later users requesting the normal URL may receive the component payload rather than the intended HTML document. The primary effects are integrity and availability degradation of rendered pages; confidentiality impact is not indicated by the advisory, but exposure may vary depending on what the application embeds in RSC payloads and how caches are configured.

Why it matters to the business

Public-facing web applications using affected Next.js versions may intermittently serve broken or incorrect pages to legitimate visitors, causing user-facing outages, degraded customer experience, failed transactions, and support burden. Because exploitation depends on cache behavior and response-variant handling, impact is most relevant for sites using CDNs, reverse proxies, or other shared caching layers in front of Next.js. The CVSS score is moderate and EPSS is currently low, with no CISA KEV listing or known ransomware association, but the issue affects a widely used web framework and should be addressed during normal patch cycles, with faster action for high-traffic or revenue-critical sites.

How an attack unfolds

An attacker first identifies a Next.js application in an affected version range that uses React Server Components and is served through a shared cache such as a CDN or reverse proxy. The attacker then crafts requests that cause the application to produce an RSC response while the cache stores that response under the original page URL rather than a correctly partitioned variant. If the cache accepts and reuses the poisoned object, subsequent users requesting the page receive the cached RSC component payload instead of the expected HTML. The attack does not require authentication or user interaction, but it has high complexity because it depends on application behavior, framework version, route configuration, request headers, and cache normalization rules.

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. Applications on 14.2.0 or later 14.x releases should upgrade to a supported fixed branch because the advisory identifies fixed versions only in the 15.x and 16.x lines. After upgrading, rebuild and redeploy the application, then purge CDN, reverse-proxy, and framework caches to remove any previously poisoned entries. As a defense-in-depth mitigation, ensure shared caches vary correctly on headers and parameters used by React Server Components, avoid caching RSC responses under normal document URLs, verify cache key configuration for RSC-related request headers, and consider disabling or bypassing shared caching for affected routes until patching is complete.

How to confirm the fix worked

Confirm all deployed Next.js applications report a fixed version: 15.5.16 or later, or 16.2.5 or later. Review lockfiles and build artifacts to ensure the patched Next.js package is actually used in production images and serverless deployments. Test representative RSC-enabled routes through the same CDN or reverse proxy used in production by requesting both normal HTML responses and RSC responses, then verify cache headers, vary behavior, content type, and response body are not reused across variants. Confirm normal page URLs return HTML documents, not RSC payloads, after cache warm-up and repeated requests. Purge shared caches and verify no stale poisoned objects remain.

Typical attack path

1. Fingerprint the target as a Next.js application using an affected version range.
2. Identify routes that use React Server Components and are cacheable by a shared intermediary such as a CDN, reverse proxy, or edge cache.
3. Send crafted requests that request or negotiate an RSC response for a normal page URL.
4. Trigger the shared cache to store the RSC response under a cache key that will also be used for ordinary HTML requests.
5. Wait for legitimate users or monitoring systems to request the affected URL.
6. Cause those users to receive component payload content instead of the intended HTML page until the cache entry expires, is purged, or is overwritten.

How to detect it

Investigate CDN, reverse-proxy, WAF, and application access logs for sequences where unusual RSC requests are followed by cache HIT responses for the same URL served to normal browsers. Focus on affected routes where normal document requests returned non-HTML content types, unusually small or structured payloads, or bodies containing React Server Components markers. Review cache logs for objects stored for ordinary page URLs after requests containing RSC-related query parameters or headers. Look for spikes in 200 responses with cache HIT status but mismatched content-type, user-agent complaints, rendering errors, or frontend monitoring events indicating invalid document responses. If full response capture or synthetic monitoring is available, search for normal page URLs returning RSC payload syntax instead of an HTML doctype or root HTML element. No named threat actors or active exploitation campaigns are currently identified in the provided intelligence.

• ?_rsc=
• RSC: 1
• Next-Router-State-Tree
• Next-Router-Prefetch
• text/x-component
• Cache-Status: hit
• CF-Cache-Status: HIT
• X-Cache: HIT
• x-nextjs-cache: HIT
• self.__next_f.push
• <!DOCTYPE html missing on normal page response

What your security team should do

• Inventory public-facing Next.js applications and identify deployments running versions from 14.2.0 up to but not including 15.5.16 or 16.2.5.
• Prioritize patching applications using React Server Components behind CDNs, reverse proxies, edge caches, or other shared caching infrastructure.
• Upgrade to Next.js 15.5.16+ or 16.2.5+, rebuild, redeploy, and purge all shared caches after deployment.
• Review CDN and reverse-proxy cache-key rules to ensure response variants are partitioned correctly and RSC responses cannot be cached as normal HTML pages.
• Temporarily bypass shared caching for RSC-enabled dynamic routes if immediate upgrade is not possible.
• Add monitoring for normal page URLs returning RSC-like payloads, unexpected content types, or anomalous cache HIT responses following RSC request patterns.
• Because EPSS is low and there is no KEV listing, handle as a moderate-priority framework patch unless the affected application is business-critical or heavily cached at the edge.