CVE-2026-44580

What it actually does

This is a cross-site scripting vulnerability in Next.js applications that use beforeInteractive scripts in combination with untrusted or attacker-controllable content. In affected versions, serialized script content is not escaped safely before being embedded into the generated document. An attacker can craft input that breaks out of the intended script context and causes arbitrary JavaScript to execute in a visitor’s browser. The impact is browser-side execution in the security context of the affected application, enabling access to page content, user-visible data, session-dependent actions, and client-side application state, subject to browser protections and cookie attributes.

Why it matters to the business

Successful exploitation can let an attacker run malicious code in users’ browsers when they view affected pages, potentially leading to account takeover workflows, fraudulent user actions, theft of non-HttpOnly tokens or sensitive page data, phishing overlays, defacement, or loss of user trust. The CVSS score is moderate and EPSS is currently low, and it is not listed in CISA KEV, but exposure may be broad because Next.js is widely used for production web applications and vulnerable patterns can appear in application-specific rendering paths.

How an attack unfolds

An attacker first identifies a Next.js application running an affected version, specifically a version from 13.0.0 up to but not including 15.5.16, or 16.x before 16.2.5. The attacker then looks for pages or components that use beforeInteractive scripts and incorporate untrusted content into serialized script data. If user-controlled input is embedded without safe escaping, the attacker crafts a payload that terminates or escapes the intended script serialization context and injects executable JavaScript. The payload must then be delivered to a victim through a vulnerable route, stored content, reflected parameters, shared links, comments, profile fields, CMS content, or another content source consumed by the affected rendering path. When the victim loads the page, the browser parses the injected content as script and executes it under the origin of the vulnerable application. The attacker can then perform actions available to the victim in the web application, read accessible DOM content, capture client-side secrets not protected by HttpOnly controls, or redirect the user to attacker-controlled flows.

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. Applications on any version from 13.0.0 through versions before those fixed releases should be treated as potentially affected if they use beforeInteractive scripts with untrusted content. If immediate upgrade is not possible, remove or refactor beforeInteractive script usage that serializes untrusted content, ensure all data embedded into script contexts is safely encoded for JavaScript/script contexts, and avoid placing user-controlled data directly into scripts. Apply defense-in-depth controls such as strict Content Security Policy with nonces or hashes, HttpOnly and SameSite cookies, output encoding by context, sanitization for user-generated content, and review of third-party/CMS content that can influence page rendering.

How to confirm the fix worked

Confirm the deployed application uses Next.js 15.5.16 or later, or 16.2.5 or later, by checking package manager lockfiles, build artifacts, dependency manifests, container images, and software composition analysis results. Search the codebase for beforeInteractive script usage, especially imports or usage of next/script with strategy="beforeInteractive", and review whether any serialized script content includes user-controlled, CMS-controlled, or third-party content. Test representative affected routes with harmless XSS canary payloads in a non-production environment to confirm that payloads are escaped rather than executed. Validate that Content Security Policy blocks inline script execution unless explicitly nonce- or hash-authorized. Confirm production deployments were rebuilt and redeployed after dependency updates, not only package files changed.

Typical attack path

1. Identify a public Next.js application and determine that it runs an affected version range.
2. Find a page using beforeInteractive scripts where untrusted content is serialized into the document.
3. Craft a payload that escapes the serialized script context and injects JavaScript.
4. Deliver the payload through a reflected input, stored content field, CMS entry, user-generated content, or shared malicious URL.
5. Wait for a victim to load the affected page.
6. Execute attacker-controlled JavaScript in the victim’s browser under the vulnerable site’s origin.
7. Use the script to steal accessible data, perform unauthorized actions as the victim, display phishing content, or pivot to further client-side compromise.

How to detect it

To determine whether exploitation has already occurred, review web access logs, WAF logs, CDN logs, application logs, CMS audit logs, and user-generated content stores for XSS payloads targeting script-context breakouts. Focus on requests or stored content containing closing script tags, JavaScript event handlers, encoded script delimiters, template-breaking sequences, and suspicious use of functions such as alert, fetch, eval, atob, document.cookie, localStorage, or location redirection. Examine referrer and query-string telemetry for shared malicious links that include encoded JavaScript. If browser telemetry, CSP violation reports, RUM, or endpoint web protection logs are available, search for blocked inline script execution, unexpected outbound requests from application pages to unfamiliar domains, or CSP reports referencing injected script samples. Review authentication and application audit logs for anomalous user actions shortly after suspicious page views, such as profile changes, email changes, token creation, unauthorized transactions, or administrative actions. Because this is client-side exploitation, server logs may show only payload delivery, not execution; CSP reports and browser-side telemetry are often the best evidence of successful execution.

• </script>
• %3C%2Fscript%3E
• <script
• %3Cscript
• onerror=
• onload=
• javascript:
• document.cookie
• localStorage
• sessionStorage
• eval(
• Function(
• setTimeout(
• setInterval(
• atob(
• btoa(
• fetch(
• XMLHttpRequest
• navigator.sendBeacon
• window.location
• location.href
• location.replace
• srcdoc=
• <img src=x onerror=
• <svg onload=
• </script><script>
• %3C%2Fscript%3E%3Cscript%3E
• strategy="beforeInteractive"
• strategy='beforeInteractive'

What your security team should do

• Inventory all Next.js applications and identify versions from 13.0.0 to before 15.5.16 and 16.2.5.
• Prioritize externally accessible applications, authenticated portals, applications handling sensitive user data, and applications with user-generated or CMS-managed content.
• Upgrade to Next.js 15.5.16 or later, or 16.2.5 or later, and rebuild/redeploy all affected services.
• Search code for next/script usage with strategy="beforeInteractive" and review any dynamic content embedded into script contexts.
• Add or tighten Content Security Policy using nonces or hashes and avoid unsafe-inline wherever feasible.
• Review logs and telemetry for suspicious script injection attempts in query strings, request bodies, referrers, CMS content, and user-generated content fields.
• Perform targeted application security testing for XSS on pages using beforeInteractive scripts.
• Ensure cookies containing session or authentication material are marked HttpOnly, Secure, and SameSite where compatible.
• Monitor dependency advisories and SCA tooling for vulnerable Next.js versions in direct and transitive application packages.