CVE-2026-44582

What it actually does

CVE-2026-44582 is a cache-poisoning weakness in Next.js React Server Component handling affecting versions from 13.4.6 before 15.5.16 and from 16.x before 16.2.5. In deployments that use shared HTTP caches or CDNs without adequate response partitioning, collisions involving the _rsc cache-busting parameter can cause an attacker-controlled or unintended React Server Component response variant to be stored and served for the same URL. The primary technical effect is low-integrity impact: users may receive the wrong server component payload or page variant. The issue does not directly provide code execution, authentication bypass, data exfiltration, or service outage based on the published description, and exploitation requires specific caching behavior, making practical exploitation higher complexity.

Why it matters to the business

Affected applications may serve incorrect page content or application state to users, which can cause user confusion, incorrect workflows, broken application behavior, or exposure of unintended UI variants. The business impact is most relevant for high-traffic applications using CDNs, reverse proxies, or other shared cache layers in front of Next.js. Because the CVSS score is low, EPSS is very low, the issue is not listed in CISA KEV, and no public exploit maturity is reported, this should generally be treated as a controlled patching priority rather than an emergency. However, organizations with shared caching in front of affected Next.js versions should prioritize review because cache poisoning issues can be difficult to diagnose once incorrect responses are propagated across edge caches.

How an attack unfolds

An attacker targets a Next.js application using React Server Components and a shared cache such as a CDN, reverse proxy, or intermediary HTTP cache. The attacker identifies routes that return React Server Component responses and observes how the application and cache treat requests containing the _rsc cache-busting value. If the shared cache does not sufficiently partition response variants by all relevant request attributes, the attacker attempts to generate colliding or ambiguous _rsc values that cause the cache to associate one response variant with another request for the same URL. Once a poisoned response is stored, subsequent users requesting the affected URL may receive the wrong React Server Component payload or page variant until the cache entry expires or is purged. Exploitation is constrained by cache configuration, application routing, and the ability to produce useful collisions, which aligns with the high attack complexity and low observed exploitation likelihood.

How to fix it

Upgrade Next.js to a fixed version: 15.5.16 or later for the 15.x release line, or 16.2.5 or later for the 16.x release line. For applications on affected 13.x or 14.x versions, upgrade to a supported fixed release line that includes the patch. In addition to upgrading, review CDN and reverse-proxy cache policies to ensure React Server Component responses are not cached incorrectly and that cache keys vary on all relevant request attributes, including query parameters such as _rsc and relevant headers used by Next.js. If immediate upgrade is not possible, consider disabling shared caching for React Server Component responses, bypassing cache for requests containing _rsc, reducing TTLs for dynamic application routes, or purging affected CDN and reverse-proxy cache entries after configuration changes. Avoid relying only on client-side cache controls if a shared intermediary cache can store responses.

How to confirm the fix worked

Confirm the deployed Next.js version is not within the affected range by checking package manifests, lockfiles, container images, build metadata, and runtime dependency inventories. Validate that next is at 15.5.16 or later, or 16.2.5 or later. Review CDN, reverse-proxy, and application cache configuration to confirm that requests containing _rsc are either not cached or are partitioned correctly in cache keys. Perform controlled testing on non-production or safely scoped routes by issuing repeated requests to the same URL with different _rsc values and verifying that the shared cache does not serve the wrong response variant. Inspect response headers such as Cache-Control, Vary, Age, X-Cache, CF-Cache-Status, CDN-Cache-Status, or equivalent vendor-specific headers to confirm expected cache behavior. After patching or cache-policy changes, purge shared cache entries for affected applications and re-test.

Typical attack path

1. Identify a public Next.js application running an affected version between 13.4.6 and before 15.5.16, or 16.x before 16.2.5.
2. Confirm that the application uses React Server Components and emits or accepts requests involving the _rsc parameter.
3. Determine whether a shared cache, CDN, reverse proxy, or intermediary cache stores React Server Component responses.
4. Probe how cache keys are constructed and whether responses are partitioned by _rsc and other relevant request headers or query parameters.
5. Craft requests with colliding or ambiguous _rsc cache-busting values for a target URL.
6. Cause the shared cache to store an unintended React Server Component response variant for that URL.
7. Wait for or induce other users to request the same URL and receive the poisoned or incorrect cached response.
8. Optionally repeat against additional routes until cache entries expire, are purged, or the application is upgraded or reconfigured.

How to detect it

To assess possible prior exploitation, review CDN, reverse-proxy, WAF, and application access logs for unusual probing of React Server Component requests involving the _rsc query parameter. Focus on repeated requests to the same URL with many different _rsc values, high rates of cache misses followed by hits for the same URL, anomalous query strings, and requests that appear designed to test cache-key behavior. Correlate cache logs with user reports of wrong content, inconsistent UI state, or page variants appearing for users who should not receive them. Examine response headers in logs, if captured, for cache-status transitions around suspicious requests. Useful log sources include CDN request logs, reverse-proxy access logs, edge cache logs, WAF logs, Next.js application logs, and synthetic monitoring traces. There are no known public threat actors, campaigns, or ransomware use associated with this vulnerability based on the supplied information, so detection should emphasize behavioral evidence of cache poisoning rather than known malware artifacts.

• _rsc=
• GET /?*_rsc=
• POST /?*_rsc=
• X-Cache: HIT
• X-Cache: MISS
• CF-Cache-Status: HIT
• CF-Cache-Status: MISS
• CDN-Cache-Status: HIT
• Cache-Control
• Vary

What your security team should do

• Inventory all externally exposed and internally important applications built with Next.js and identify versions from 13.4.6 before 15.5.16 and 16.x before 16.2.5.
• Prioritize remediation for applications behind shared CDNs, reverse proxies, edge caches, or multi-tenant caching layers.
• Upgrade Next.js to 15.5.16 or later, or 16.2.5 or later, and rebuild/redeploy affected applications.
• Temporarily bypass shared caching for React Server Component responses or requests containing _rsc if upgrades cannot be deployed promptly.
• Review cache-key configuration to ensure query parameters and relevant request headers are included where necessary, and purge existing cache entries after changes.
• Add monitoring for unusual volumes of requests containing _rsc, repeated variant probing, cache misses followed by broad cache hits, and user reports of incorrect page content.
• Because this issue is not in CISA KEV, has very low EPSS, and has no reported exploit maturity, handle through prioritized patch management rather than emergency incident response unless suspicious cache behavior is observed.