5.4

CVSS Score

3.1

-

CVSS Score

Basic Information

Concerned about an active attack path?

Talk to our security experts and see Miggo in action.

Miggo Vulnerability Database

→

CVE-2026-44576

CVE-2026-44576: Next.js: Cache poisoning in React Server Component responses

Next.js is a React framework for building full-stack web applications. From 14.2.0 to before 15.5.16 and 16.2.5, 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. This vulnerability is fixed in 15.5.16 and 16.2.5.

(GitHub Advisory)

Miggo Vulnerability Database

→

CVE-2026-44576

CVE-2026-44576:

5.4

CVSS Score

3.1

-

CVSS Score

Basic Information

Is this CVE running in your environment?

Easily map the attack path and prioritize which CVEs are a threat to your organization

Validate Exposure

Technical Details

Package Name	Ecosystem	Vulnerable Versions	First Patched Version
next	npm	>= 14.2.0, < 15.5.16	15.5.16
next	npm	>= 16.0.0, < 16.2.5	16.2.5

Technical Details

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

The vulnerability, identified as GHSA-wfc6-r584-vfw7, is a cache poisoning issue in Next.js applications using React Server Components (RSC). The root cause was an inconsistent interpretation of the RSC request header across different parts of the application and infrastructure (like CDNs or reverse proxies). An attacker could send a request with a malformed RSC header (e.g., RSC: 0 or RSC: true instead of the expected RSC: 1). Some parts of the Next.js server would interpret this loosely (e.g., using Boolean(header_value)) and treat it as a valid RSC request, while a cache might not, or vice-versa. This discrepancy allowed an attacker to poison the cache, causing subsequent users requesting a normal HTML page to receive a raw RSC data payload, breaking the page.

The fix, identified in commit 0dd94836a8b43209fcfefa448c141683c22c1a27, was to introduce a strict validation function, isRSCRequestHeader, which only accepts the literal string '1' as a valid indicator of an RSC request. This function was then applied consistently across all points where the RSC header is inspected, including the main request handler, route resolvers, and rendering logic. By enforcing a single, strict interpretation of the header, the patch eliminates the ambiguity that led to the cache poisoning vulnerability.

Vulnerable functions

handler

packages/next/src/build/templates/app-page.ts

The `handler` function in `app-page.ts` used a weak `Boolean()` check on the `RSC` header. This could lead to an inconsistent interpretation of the request compared to other parts of the system (like a CDN), allowing an attacker to poison the cache by sending a malformed header value that evaluates to `true`.

parseRequestHeaders

packages/next/src/server/app-render/app-render.tsx

The `parseRequestHeaders` function considered any defined value for the `RSC` header as a valid RSC request. This is too permissive and contributes to the interpretation conflict. The fix was to use the strict `isRSCRequestHeader` function, which only allows the value '1'.

Server.handleRequest

packages/next/src/server/base-server.ts

The main request handling logic within the `Server` class was modified to use the new `isRSCRequestHeader` function for consistency. While some parts already checked for `=== '1'`, standardizing this check across the entire request lifecycle is crucial to prevent any discrepancies that could be exploited for cache poisoning.

adapter

packages/next/src/server/web/adapter.ts

The `adapter` function, which handles web requests, was updated to use the centralized `isRSCRequestHeader` check. This ensures that requests passing through this adapter are classified consistently with the rest of the Next.js server, mitigating the risk of interpretation conflicts.

getResolveRoutes

packages/next/src/server/lib/router-utils/resolve-routes.ts

The `getResolveRoutes` function was part of the inconsistent handling of the `RSC` header. Although it was already checking for the specific value '1', the patch updated it to use the new shared `isRSCRequestHeader` function. This change was part of a broader effort to enforce a single, consistent validation logic across the codebase to eliminate any potential for interpretation conflicts that could lead to cache poisoning.

Vulnerability Intelligence
Miggo AI

Unlock WAF rules for this CVE

Generate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance

Get WAF rules

WAF Protection Rules

WAF Rule

W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.

Reasoning

*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.