CVE-2026-44581

What it actually does

This flaw affects Next.js App Router applications from 13.4.0 up to, but not including, 15.5.16 and 16.2.5 when they rely on CSP nonces and are deployed behind shared caches such as CDNs or reverse proxies. Malformed nonce values derived from request headers can be reflected into server-rendered HTML without safe handling. If that response is stored by a shared cache, later visitors can receive attacker-poisoned HTML that executes injected JavaScript in their browsers. The vulnerability is a stored cross-site scripting issue with network reachability, no authentication requirement, and user interaction required because victims must load the poisoned page.

Why it matters to the business

A successful attack can cause visitors to a cached page to run attacker-controlled JavaScript, potentially leading to session theft, account actions performed as the user, content manipulation, phishing, or exposure of sensitive page data. Operationally, the main risk is loss of trust in public-facing web applications and the need to purge caches, rotate potentially exposed tokens, and investigate user impact. Although the CVSS score and EPSS probability are currently low and it is not listed in CISA KEV, the issue is important for high-traffic Next.js applications because one poisoned cache entry can affect many users until it expires or is purged.

How an attack unfolds

An attacker identifies a Next.js App Router application using CSP nonces and served through a shared cache. They send a crafted request containing a malformed nonce-related header value designed to break out of the expected nonce context and inject script-capable markup into the rendered HTML. If the response is cacheable and the cache key does not vary safely on the relevant request attributes, the CDN or reverse proxy stores the malicious response. Later, legitimate users request the same page and receive the cached poisoned HTML. Their browsers execute the injected JavaScript in the context of the affected application, allowing the attacker to read accessible page data, perform actions as the user, redirect users, or capture tokens that are exposed to client-side JavaScript.

How to fix it

Upgrade Next.js to a fixed version: 15.5.16 or later for the 15.x line, or 16.2.5 or later for the 16.x line. Applications on 13.x or 14.x should move to a supported fixed release rather than relying on workaround-only mitigation. After upgrading, rebuild and redeploy all affected applications and purge CDN/reverse-proxy caches so previously poisoned HTML cannot continue to be served. As defense in depth, generate CSP nonces server-side using cryptographically random values, restrict nonce format to a safe character set such as base64/base64url, never derive trusted nonce values directly from attacker-controllable request headers, reject malformed CSP/nonce inputs, and ensure shared caches do not store user-influenced dynamic HTML unless cache keys and Vary behavior are explicitly safe.

How to confirm the fix worked

Confirm the deployed Next.js version with package metadata and dependency tooling such as `npm ls next`, `pnpm why next`, `yarn why next`, or lockfile review, and verify the runtime deployment is using 15.5.16 or later, or 16.2.5 or later. Test representative App Router pages behind the same CDN or reverse proxy by sending requests with malformed nonce-like header values containing characters such as `<`, `>`, quotes, and script fragments, then inspect the returned HTML to ensure those values are not reflected into nonce attributes or script contexts. Verify that dynamic HTML responses using CSP nonces are not cacheable unless intentionally safe, and confirm CDN cache keys and Vary headers prevent attacker-controlled header values from poisoning shared cache entries. Purge caches after remediation and retest that repeated requests return clean HTML.

Typical attack path

1. Find a public Next.js App Router route that uses CSP nonces and is served through a shared cache.
2. Send requests with malformed nonce-related header values containing HTML or JavaScript-breaking characters.
3. Cause the application to render the malformed nonce value into the HTML response unsafely.
4. Trigger cache storage by ensuring the response is considered cacheable by the CDN, reverse proxy, or intermediary cache.
5. Wait for later users to request the same cached URL and receive the poisoned response.
6. Execute attacker-controlled JavaScript in victim browsers under the affected application's origin.
7. Use the script to steal accessible data, manipulate page content, perform user actions, or redirect users to attacker-controlled pages.

How to detect it

Investigate CDN, reverse-proxy, WAF, application access logs, cache logs, and CSP violation reports. Look for requests to App Router pages with unusual CSP or nonce-related header values containing HTML metacharacters, encoded script tags, quotes, event-handler names, or `javascript:` URLs. Pay special attention to cache MISS events from a small number of source IPs followed by many cache HIT events for the same URL, because that pattern can indicate successful cache poisoning. Inspect stored CDN or reverse-proxy cached HTML, if available, for malformed `nonce` attributes or unexpected inline scripts. Review browser-side CSP reports for blocked inline script execution, unexpected script sources, or violations tied to pages that should only contain framework-generated scripts. If logs include response bodies or security telemetry, search for nonce attributes containing anything other than expected random base64/base64url values.

• nonce="<
• nonce='<
• nonce="%3C
• nonce='%3C
• script-src 'nonce-<
• script-src 'nonce-%3C
• </script><script
• %3C/script%3E%3Cscript
• <script>alert
• %3Cscript%3Ealert
• onerror=
• onload=
• javascript:
• Content-Security-Policy: script-src 'nonce-<
• Content-Security-Policy: script-src 'nonce-%3C
• x-middleware-prefetch
• __next_f.push

What your security team should do

• Inventory externally reachable Next.js App Router applications and prioritize those using CSP nonces behind CDNs, reverse proxies, or other shared caches.
• Upgrade affected applications to Next.js 15.5.16 or later, or 16.2.5 or later, then rebuild, redeploy, and purge all edge and intermediary caches.
• Review cache-control, CDN cache-key, and Vary-header configuration for dynamic HTML routes that depend on request headers.
• Add WAF or edge filtering to block nonce/CSP-related request header values containing HTML metacharacters, script tags, event handlers, or JavaScript URLs.
• Enable or review CSP violation reporting to identify attempted script execution from injected or unexpected inline scripts.
• Search CDN, reverse-proxy, WAF, and application logs for cache MISS requests with suspicious nonce-like header values followed by HIT traffic to the same URL.
• If exploitation is suspected, preserve cached objects, purge affected URLs, rotate exposed client-side tokens where applicable, and assess impacted user sessions.