A vulnerability affects certain React Server Components packages for versions 19.x and frameworks that use the affected packages, including Next.js 13.x, 14.x, 15.x, and 16.x using the App Router. The issue is tracked upstream as CVE-2026-23870.
A specially crafted HTTP request can be sent to any App Router Server Function endpoint that, when deserialized, may trigger excessive CPU usage. This can result in denial of service in unpatched environments.
Impact
Applications using the Pages Router with
i18nconfigured and middleware/proxy-based authorization can allow unauthorized access to protected page data through locale-less/_next/data/<buildId>/<page>.jsonrequests. In affected configurations, middleware does not run for the unprefixed data route, allowing an attacker to retrieve SSR JSON for protected pages without passing the intended authorization checks.Fix
The matcher logic was updated to perform the same match as it would on a non-i18n data route.
Workarounds
If you cannot upgrade immediately, enforce authorization in the page's server-side data path instead of relying solely on middleware.
Impact
App Router applications that rely on middleware or proxy-based checks for authorization can allow unauthorized access through transport-specific route variants used for segment prefetching. In affected configurations, specially crafted
.rscand segment-prefetch URLs can resolve to the same page without being matched by the intended middleware rule, which can allow protected content to be reached without the expected authorization check.Fix
We now include App Router transport variants when generating middleware matchers, so middleware protections are applied consistently to those requests as well as to the normal page URL.
Workarounds
If you cannot upgrade immediately, enforce authorization in the underlying route or page logic instead of relying solely on middleware.
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
RSCrequest 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.
Impact
Applications that rely on middleware to protect dynamic routes can be vulnerable to authorization bypass. In affected deployments, specially crafted query parameters can alter the dynamic route value seen by the page while leaving the visible path unchanged, which can allow protected content to be rendered without passing the expected middleware check.
Fix
We now only honor internal route-parameter normalization in trusted routing flows and ignore externally supplied parameter encodings that should never have been accepted from ordinary requests.
Workarounds
If you cannot upgrade immediately, enforce authorization in route or page logic instead of relying solely on middleware path matching.
Impact
Self-hosted applications using the built-in Node.js server can be vulnerable to server-side request forgery through crafted WebSocket upgrade requests. An attacker can cause the server to proxy requests to arbitrary internal or external destinations, which may expose internal services or cloud metadata endpoints. Vercel-hosted deployments are not affected.
Fix
We now apply the same safety checks to WebSocket upgrade handling that already existed for normal HTTP requests, so upgrade requests are only proxied when routing has explicitly marked them as safe external rewrites.
Workarounds
If you cannot upgrade immediately, do not expose the origin server directly to untrusted networks. If WebSocket upgrades are not required, block them at your reverse proxy or load balancer, and restrict origin egress to internal networks and metadata services where possible.
Impact
When self-hosting Next.js with the default image loader, the Image Optimization API fetches local images entirely into memory without enforcing a maximum size limit. An attacker could cause out-of-memory conditions by requesting large local assets from the
/_next/imageendpoint that match theimages.localPatternsconfiguration (by default, all patterns are allowed).
- If you are using
images.localPatterns, only the patterns in that array are impacted.- If you are using
images.unoptimized: true, you are NOT impacted.- If you are using
images.loader: 'custom', you are NOT impacted.- If you are using Vercel, you are NOT impacted.
Fix
We now apply response size limits consistently to internal image fetches, not just external ones, and fail oversized responses before they can exhaust process memory.
This can be adjusted using the
images.maximumResponseBodyconfiguration.Workarounds
If you cannot upgrade immediately, avoid routing large local assets through
/_next/image, disable image optimization for large or untrusted local files, or block image optimization access to those assets at the edge.You can disable using the
images.localPatterns: []configuration. This will still allow fetching remote images (which is not impacted).
Impact
Applications using Partial Prerendering through the Cache Components feature can be vulnerable to connection exhaustion through crafted POST requests to a server action. In affected configurations, a malicious request can trigger a request-body handling deadlock that leaves connections open for an extended period, consuming file descriptors and server capacity until legitimate users are denied service.
Fix
We now treat the header used for resuming Partial Prerendered requests as an internal-only header and strip it from untrusted incoming requests. This header should never be accepted directly from external clients.
Workarounds
If you cannot upgrade immediately, block requests that would be handled by Next.js if they contain the
Next-Resumeheader at the edge.
Impact
Applications that use
beforeInteractivescripts together with untrusted content can be vulnerable to cross-site scripting. In affected versions, serialized script content was not escaped safely before being embedded into the document, which could allow attacker-controlled input to break out of the intended script context and execute arbitrary JavaScript in a visitor's browser.Fix
We now HTML-escape serialized
beforeInteractivescript content before embedding it into the page, preventing attacker-controlled content from breaking out of the inline script boundary.Workarounds
If you cannot upgrade immediately, do not pass untrusted data into
beforeInteractivescripts. If that pattern is unavoidable, sanitize or escape the content before embedding it.
Impact
React Server Component responses can be vulnerable to cache poisoning in deployments that rely on shared caches with insufficient response partitioning. In affected conditions, collisions in the
_rsccache-busting value can allow an attacker to poison cache entries so users receive the wrong response variant for a given URL.Fix
We strengthened the
_rsccache-busting mechanism to make practical collisions significantly harder and to better separate response variants that should not share cache entries.Workarounds
If you cannot upgrade immediately, ensure intermediary caches correctly honor
Varyfor RSC-related request headers, or disable shared caching for affected RSC responses until you can deploy a patched release.
Impact
App Router applications that rely on CSP nonces can be vulnerable to stored cross-site scripting when deployed behind shared caches. In affected versions, malformed nonce values derived from request headers could be reflected into rendered HTML in an unsafe way, allowing an attacker to poison cached responses and cause script execution for later visitors.
Fix
We now reject or ignore malformed nonce values before they are embedded into HTML and apply stricter nonce sanitization so request-derived nonce data cannot break out of the intended attribute context.
Workarounds
If you cannot upgrade immediately, strip inbound
Content-Security-Policyrequest headers from untrusted traffic.
Impact
Next.js uses the
x-nextjs-datarequest header for internal data requests. On affected versions, an external client could send this header on a normal request to a path handled by middleware that returns a redirect.When that happened, the middleware/proxy could treat the request as a data request and replace the standard
Locationredirect header with the internalx-nextjs-redirectheader. Browsers do not followx-nextjs-redirect, so the response became an unusable redirect for normal clients.If the application was deployed behind a CDN or reverse proxy that caches 3xx responses without varying on this header, a single attacker request could poison the cached redirect response for the affected path. Subsequent visitors could then receive a cached redirect response without a
Locationheader, causing a denial of service for that redirect path until the cache entry expired or was purged.Affected scenarios
This affects applications that:
- use middleware or proxy redirects
- are deployed behind a caching CDN or reverse proxy
- allow 3xx responses on those paths to be cached without differentiating internal data requests from normal requests
Fix
The fix stops trusting
x-nextjs-databy itself for middleware redirect handling. A request is now treated as an internal data request only when it is validated as such by internal routing state, preserving legitimate data-request redirect behavior while preventing external header injection from changing normal redirect responses.Workarounds
Before upgrading, users can reduce risk by:
- configuring the CDN or reverse proxy to vary its cache key on
x-nextjs-datafor affected responses
Impact
It was found that the fix addressing CVE-2026-44575 did not apply to
middleware.tswith Turbopack. Refer to CVE-2026-44575 for further details.References
This release contains security fixes for the following advisories:
High:
- GHSA-8h8q-6873-q5fj: Denial of Service with Server Components
- GHSA-267c-6grr-h53f: Middleware / Proxy bypass in App Router applications via segment-prefetch routes
- GHSA-26hh-7cqf-hhc6: Middleware / Proxy bypass in App Router applications via segment-prefetch routes - Incomplete Fix Follow-Up
- GHSA-mg66-mrh9-m8jx: Denial of Service via connection exhaustion in applications using Cache Components
- GHSA-492v-c6pp-mqqv: Middleware / Proxy bypass through dynamic route parameter injection
- GHSA-c4j6-fc7j-m34r: Server-side request forgery in applications using WebSocket upgrades
- GHSA-36qx-fr4f-26g5: Middleware / Proxy bypass in Pages Router applications using i18n
Moderate:
- GHSA-ffhc-5mcf-pf4q: Cross-site scripting in App Router applications using CSP nonces
- GHSA-gx5p-jg67-6x7h: Cross-site scripting in beforeInteractive scripts with untrusted input
- GHSA-h64f-5h5j-jqjh: Denial of Service in the Image Optimization API
- GHSA-wfc6-r584-vfw7: Cache poisoning in React Server Component responses
Low:
This release contains security fixes for the following advisories:
High:
- GHSA-8h8q-6873-q5fj: Denial of Service with Server Components
- GHSA-267c-6grr-h53f: Middleware / Proxy bypass in App Router applications via segment-prefetch routes
- GHSA-mg66-mrh9-m8jx: Denial of Service via connection exhaustion in applications using Cache Components
- GHSA-492v-c6pp-mqqv: Middleware / Proxy bypass through dynamic route parameter injection
- GHSA-c4j6-fc7j-m34r: Server-side request forgery in applications using WebSocket upgrades
- GHSA-36qx-fr4f-26g5: Middleware / Proxy bypass in Pages Router applications using i18n
Moderate:
- GHSA-ffhc-5mcf-pf4q: Cross-site scripting in App Router applications using CSP nonces
- GHSA-gx5p-jg67-6x7h: Cross-site scripting in beforeInteractive scripts with untrusted input
- GHSA-h64f-5h5j-jqjh: Denial of Service in the Image Optimization API
- GHSA-wfc6-r584-vfw7: Cache poisoning in React Server Component responses
Low:
Does any of this look wrong? Please let us know.
See the full diff on Github. The new version differs by 36 commits:
v16.2.6Turbopack:
Match proxy matchers with webpack implementation
(#93594)Turbopack:
Fix middleware matcher suffix (#93590)[backport]
Disable build caches for production/staging/force-preview deploys
(#93586)[backport][test]
Pin package manager to patch versions (#93595)[backport]
Turbopack: more strict vergen setup (#93587)v16.2.5fix:
add explicit checks for RSC header (#83) (#98)fix
proxy matching for segment prefetch URLs (#89) (#96)Strip
next-resume header from incoming requests (#92)fix:
skip internal param normalization in unsupported
environmentsMove
htmlescape to shared/lib (#91)Ignore
malformed CSP nonce headersrouter-server:
guard upgrade proxy against absolute-url SSRF (#77)Fix
i18n middleware matching for default-locale data routes
(#82)[16.x]
Type hardening and performance improvements (#80)Escape
properties for beforeInteractive scripts (#86)[backport]
fix: preserve HTTP access fallbacks during prerender recovery
(#93470)[backport]
[test] Deflake `instant-navs-devtools` (#93534)[backport]
Fix double-encoding of URL pathname parts in client param parsing
(#93506)[backport]
fix accidental test duplication (#93507)[backport]
Include deployment id in `cacheHandlers` keys (#93471)CI:
Download and run self-contained datadog-ci instead of using pnpm dlx or
npx (#92546)[ci]:
trigger signed release commit via API (#93285)[ci]:
app-based release workflow (#93245)[ci]:
add environment to publishRelease flow (#93093)[ci]:
remove publish token in favor of OIDC (#93065)Fix
fallback route params case in app-page handler (#93109)[ci]:
switch to GitHub runners (#93164)Fix
invalid HTML response for route-level RSC requests in deployment adapter
(#91541)[tests]:
fix cache-components.test.ts type error (#93113)test:
scope css data-url typing to fixture (#91877)Patch
setHeader for direct route handlers (#93101)Strengthen
_rsc cache-busting param (#92755)fix(next/image):
ensure `images.maximumResponseBody` applies to local images too
(#92920)Ensure
x-nextjs-data header is only set during resolve (#92752)
- @depfu rebase
- Rebases against your default branch and redoes this update
- @depfu recreate
- Recreates this PR, overwriting any edits that you've made to it
- @depfu merge
- Merges this PR once your tests are passing and conflicts are resolved
- @depfu cancel merge
- Cancels automatic merging of this PR
- @depfu close
- Closes this PR and deletes the branch
- @depfu reopen
- Restores the branch and reopens this PR (if it's closed)
- @depfu pause
- Ignores all future updates for this dependency and closes this PR
- @depfu pause [minor|major]
- Ignores all future minor/major updates for this dependency and closes this PR
- @depfu resume
- Future versions of this dependency will create PRs again (leaves this PR as is)