CVE-2026-44573, CVE-2026-44577, CVE-2026-44572: Three Next.js Vulnerabilities Affecting EOL versions
Three New Next.js CVEs: Middleware Bypass, Image DoS, and Cache Poisoning in EOL Versions. Here is what each one does, who is exposed, and how to resolve them.
On May 13, 2026, the Vercel security team disclosed new vulnerabilities in Next.js, three of them with impact to end-of-life (EOL) versions tracked as CVE-2026-44573 (High, CVSS 7.5), CVE-2026-44577
(Medium, CVSS 5.9), and CVE-2026-44572 (Low per GitHub Security Advisory at CVSS 3.7, Medium per NVD at CVSS 5.9). All three are fixed upstream in Next.js v15.5.16 and v16.2.5, but not for EOL version.
This post summarizes each vulnerability, what is in scope, and how applications on EOL Next.js versions (anything prior to 15.5.x per the Next.js support policy) can resolve all three without an emergency migration.
What is CVE-2026-44573? Next.js Middleware Bypass in i18n Pages Router Applications
When i18n is configured, Next.js prepends a required :nextInternalLocale segment to every middleware matcher regex. A request to /_next/data/<buildId>/<page>.json without a locale prefix fails the matcher, so middleware is skipped entirely. The _next/data catch-all route then assigns the default locale and serves the page's getServerSideProps output, returning protected SSR JSON without running the middleware that was supposed to gate the request.
Because <buildId> is publicly visible inside any rendered page's __NEXT_DATA__ payload, the data URL is trivially constructible. Any flow that relies on middleware for authentication, role enforcement, or proxy authorization is exposed. This is conceptually similar to CVE-2025-29927, the 2025 middleware authorization bypass HeroDevs covered in March 2025: another case where middleware was treated as a security boundary that, under the right request shape, was never invoked.
What is CVE-2026-44577? Denial of Service in the Next.js Image Optimization API
When Next.js is self-hosted with the default image loader, the Image Optimization API fetches local images entirely into memory without enforcing a maximum size limit. An attacker who requests large local assets from the /_next/image endpoint that match the images.localPatterns configuration (by default, all patterns are allowed) can drive the application process into an out-of-memory condition.
The fix applies response size limits consistently to internal image fetches (not just external ones), rejecting oversized responses before they exhaust process memory. The limit is configurable via images.maximumResponseBody. Applications are not affected if they use images.unoptimized: true, images.loader: 'custom', or run on Vercel.
This is the second image-pipeline DoS vulnerability, the first one was CVE-2026-27980, which exhausted disk space rather than memory. Together they illustrate that the /_next/image endpoint exposes distinct resource-exhaustion surfaces. Organizations running self-hosted Next.js should treat the image pipeline as an attacker-reachable resource path that needs both memory and disk bounds.
What is CVE-2026-44572? Cache Poisoning of Next.js Middleware Redirects via x-nextjs-data
The edge-middleware adapter at packages/next/server/web/adapter.ts reads request.headers['x-nextjs-data'] to decide whether to convert a middleware-issued redirect into the internal x-nextjs-redirect form. Because the inbound header is trusted verbatim, any external client can set x-nextjs-data: 1 on a normal page request that is handled by middleware returning a redirect. The adapter then swaps the standard Location header for the internal x-nextjs-redirect header, which browsers do not follow, producing a broken redirect response.
If the application is deployed behind a CDN or reverse proxy that caches 3xx responses without varying on x-nextjs-data, a single attacker request can poison the cached redirect for that path. Subsequent legitimate visitors receive a cached redirect with no Location header, causing a denial of service on that redirect path until the cache entry expires or is purged. The fix stops trusting the inbound header alone and instead validates internal data-request state via internal routing.
Applications hosted on platforms that handle middleware at the platform level, such as Vercel, are not affected.
Why Do These Next.js CVEs Matter?
These three CVEs are not a coincidence of unrelated bugs. They share a common surface: the boundary between an externally controlled request and Next.js internal routing primitives. CVE-2026-44573 lets external requests reach an internal data route that should have gone through middleware. CVE-2026-44572 lets external requests inject an internal header that should only ever be set by Next.js itself. CVE-2026-44577 lets external requests reach a self-hosted image fetch path with no resource bound on the response. In every case, an attacker-controlled request manipulates a component that was assumed to be operating on trusted, internally generated inputs.
For self-hosted teams, this disclosure batch matters for three concrete reasons:
- Middleware-as-authorization is not safe by default on EOL versions. If your team uses Next.js middleware to gate authenticated routes (a common pattern for SaaS dashboards and admin consoles), CVE-2026-44573 means that on any release prior to v15.5.16, the protection can be bypassed by changing the URL shape. This compounds the prior middleware-bypass class established by CVE-2025-29927.
- Self-hosted image optimization needs explicit bounds. Anyone running Next.js outside Vercel with default image config is exposed to memory exhaustion until they upgrade or apply a resolved version. The standard mitigation guidance ("just use a CDN") is not a substitute for a fix when the malicious request targets local patterns.
- EOL Next.js versions will not be resolved upstream. Per the Next.js support policy, versions prior to 15.5.x are end-of-life. All three CVEs cover ranges that go back to v10.0.0 or v12.2.0, but the upstream fix only ships in v15.5.16 and v16.2.5. For teams on v10, v11, v12, v13, or v14, there is no upstream fix at all.
This is the same pattern HeroDevs covered in our March 2026 roundup of CVE-2026-29057 and CVE-2026-27980: real CVEs disclosed against the current LTS line, but with affected version ranges that reach years into EOL territory. Each disclosure widens the gap between what is publicly known about Next.js vulnerabilities and what is patched in the versions enterprises are actually running.
How Does NES for Next.js Resolve These Vulnerabilities?
NES for Next.js v12.3.14 resolves all three vulnerabilities for customers running Next.js v12.3.x. With a drop-in replacement there are no code changes, no migration, and no breaking changes to application behavior. Customers update their next package versions and the fixes ship with them.
FAQ
Are Vercel-hosted Next.js applications affected? Vercel-hosted applications are not affected by CVE-2026-44577 (image DoS) or CVE-2026-44572 (cache poisoning), because Vercel handles middleware and image optimization at the platform level. CVE-2026-44573 affects all Next.js Pages Router applications that use both i18n and middleware-based authorization, regardless of host.
Can these vulnerabilities be exploited without authentication? Yes. All three have PR:N (Privileges Required: None) in their CVSS vectors. No credentials are required. CVE-2026-44573 is AC:L (Attack Complexity: Low), meaning a simple unauthenticated request to the locale-less data route is enough to trigger the bypass.
Do we still need to act if we are already planning a migration to Next.js 16? Yes. The exposure window between disclosure (May 13, 2026) and the completion of a major-version migration is exactly when these CVEs are most likely to be exploited. If your migration is not complete within days, apply the upstream fix on your current major version (v15.5.16 if you are on 15.5.x) or move to a resolved NES release.
Does NES for Next.js cover future CVEs in this version range? Yes. NES for Next.js provides ongoing security maintenance for EOL Next.js versions, including resolution of newly disclosed CVEs in lockstep with the upstream disclosure timeline. Customers running v12.3.x receive secure drop-in replacements with each new advisory.
Resolve Three Next.js CVEs in EOL Versions Today
Multiple CVEs in a single Next.js disclosure batch, all with affected EOL versions, is exactly the scenario NES for Next.js exists to address. If your team is running Next.js v10 through v15.4 in production, the upstream project will not ship a fix for any of these vulnerabilities. Migration to v15.5.16 or v16.2.5 is the long-term answer, but for most organizations a full Next.js major-version upgrade is months of engineering work. Every day between disclosure and patch is exposure. NES for Next.js v12.3.14 ships a secure drop-in replacement that does not require migration and has no breaking changes. Talk to HeroDevs about NES for Next.js to get pricing, version coverage details, and a same-day path to a resolved release.
For continued coverage of Next.js CVE activity, see our prior posts:
