Next.js CVE-2026-44576
MEDIUM
GHSA-wfc6-r584-vfw7
Severity by source
AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:L
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:L
Lifecycle Timeline
3Blast Radius
ecosystem impact- 4,044 npm packages depend on next (62 direct, 3,985 indirect)
Ecosystem-wide dependent count for version 14.2.0.
DescriptionGitHub Advisory
Impact
Applications using React Server Components can be vulnerable to cache poisoning when shared caches do not correctly partition response variants. Under affected conditions, an attacker can cause an RSC response to be served from the original URL and poison shared cache entries so later visitors receive component payloads instead of the expected HTML.
Fix
We now validate and interpret RSC request headers consistently across request classification and rendering, and we enforce the intended cache-busting behavior so RSC payloads are not unexpectedly served from the original URL.
Workarounds
If you cannot upgrade immediately, ensure your CDN or reverse proxy keys on the relevant RSC request headers and honors Vary, or disable shared caching for affected App Router and RSC responses.
AnalysisAI
Cache poisoning in React Server Components allows remote attackers to serve malicious RSC payloads from legitimate URLs when shared caches (CDNs, reverse proxies) do not properly partition response variants by RSC request headers. An attacker can manipulate cache entries so subsequent legitimate users receive component serialization instead of expected HTML, enabling information disclosure and application malfunction. This affects Next.js 14.2.0-15.5.15 and 16.0.0-16.2.4 using App Router with shared caching; no public exploit code identified at time of analysis.
Technical ContextAI
React Server Components (RSCs) in Next.js use a specialized request header (RSC) to communicate whether the client is requesting HTML or serialized component payloads. The vulnerability stems from improper handling of cache key construction (CWE-436: Untrusted Specification of Manifest Validation Rules) when shared caches (HTTP-level CDNs, reverse proxies) do not correctly use the RSC header and Vary header to partition cached responses. The root cause is inconsistent interpretation of the RSC request header across request classification and rendering pipelines, allowing an attacker to craft requests that cause the cache layer to serve RSC serialization data from the original HTML URL. The fix enforces consistent header validation and cache-busting behavior to ensure RSC payloads are never delivered from paths intended for HTML.
RemediationAI
Vendor-released patch: upgrade to Next.js 15.5.16 or later for the 15.x branch, or 16.2.5 or later for the 16.x branch. If immediate upgrade is not possible, implement compensating controls: configure your CDN or reverse proxy to key cache entries on RSC request headers (examine the RSC header value in request classification) and honor the Vary response header to ensure RSC and HTML responses are not collapsed into a single cache entry; alternatively, disable shared caching entirely for App Router routes and RSC endpoints by setting Cache-Control: private or removing Cache-Control: public from RSC responses. The latter trades reduced performance for complete elimination of cache poisoning risk and is appropriate for sensitive applications. Verify that your cache layer respects Vary headers - many legacy reverse proxies do not, and CDN documentation should be consulted to confirm RSC header support.
Same weakness CWE-436 – Interpretation Conflict
View allSame technique Information Disclosure
View allVendor StatusVendor
Share
External POC / Exploit Code
Leaving vuln.today