CVE-2026-44572
Vercel Next.Js 12.2.0 – 15.5.16
Raw vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:LSummary
CVE-2026-44572 is a low-severity Acceptance of Extraneous Untrusted Data With Trusted Data (CWE-349) vulnerability in Vercel Next.Js. Its CVSS base score is 3.7 (Low).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploit Public-Facing Application (T1190); ranked at the 21th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SI-10 (Information Input Validation) and CM-6 (Configuration Settings) — see the control section below for these in your framework.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-30051
Vulnerability Data
Next.js is a React framework for building full-stack web applications. From 12.2.0 to before 15.5.16 and 16.2.5, an external client could send a x-nextjs-data header on a normal request to a path handled by middleware that returns a redirect. When…
more
that happened, the middleware/proxy could treat the request as a data request and replace the standard Location redirect header with the internal x-nextjs-redirect header. Browsers do not follow x-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 Location header, causing a denial of service for that redirect path until the cache entry expired or was purged. This vulnerability is fixed in 15.5.16 and 16.2.5.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise TechniquesAI
Why these techniques?
Vulnerability in public-facing Next.js web framework directly enables exploitation via crafted request headers leading to cache poisoning and DoS.
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
Mitigating Controls (NIST 800-53 r5) AI
Directly mitigates acceptance of the untrusted x-nextjs-data header on normal requests, preventing the middleware from emitting a non-standard redirect header that breaks client handling.
Boundary protection devices (CDNs/reverse proxies) can enforce header normalization, Vary handling, and cache-key rules that block poisoning of 3xx responses for paths behind middleware.
Requires explicit configuration of cache-control and Vary headers on redirect responses so that CDN/proxy caches do not serve header-less Location responses to subsequent clients.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly address proper trust-boundary enforcement and input validation, preventing this class of weakness during development.
Cryptographic integrity checks on data-at-rest can detect tampering or substitution of untrusted content mixed with trusted data.
Cryptographic integrity mechanisms on data-in-transit can prevent acceptance of extraneous untrusted data by validating origin and detecting modification.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing can detect the weakness but does not itself implement preventive controls.
Secure development lifecycle mandates input validation and trust-boundary enforcement that directly prevents acceptance of untrusted data alongside trusted data.
Application security requirements explicitly call for strict separation and validation of trusted versus untrusted data sources.
Secure architecture principles require explicit trust boundaries and data-origin checks that mitigate mixing of trusted and untrusted inputs.
Secure coding standards mandate input sanitization and provenance checks that prevent acceptance of extraneous untrusted data.
Information access restriction limits who can supply data but does not address validation of data origin or trust level.
Hardening callouts derived
Configuration rules from DISA STIG baselines that reduce the attack surface for weaknesses of the type cited by this CVE. Derived transitively via CVE→CWE→STIG over `controls_xwalks` (authoritative rows only).
Oracle Linux 8 (2 rules)
- V-248574 YUM must be configured to prevent the installation of patches, service packs, device drivers, or OL 8 system components that have not been digitally signed using a certificate that is recognized and approved by the organization. via CWE-349
- V-248575 OL 8 must prevent the installation of software, patches, service packs, device drivers, or operating system components of local packages without verification they have been digitally signed using a certificate that is issued by a Certificate Authority (CA) that is recognized and approved by the organization. via CWE-349