CVE-2026-45109
High · 7.5CVSS
7.5
EPSS
0.8%
Published
May 13, 2026
CISA due date
—
Cloudanix analysis
Some Next.js websites may let outsiders view pages or data that should require a login, so affected applications need to be updated and retested.
- Exploitation
- Remote Unauthenticated
- Attacker needs
- None
- Complexity
- Low
- Impact
- Data Exposure
- Component
- Web Framework
- Class
- Authentication Bypass
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
The flaw is an authentication-bypass issue in Next.js applications using affected 15.x or 16.x releases with Turbopack and middleware defined in middleware.ts. A prior security fix did not apply correctly in this code path, allowing requests that should be evaluated or blocked by middleware-based access-control logic to reach protected application routes. The primary technical consequence is unauthorized disclosure of protected content or data, reflected by the CVSS impact emphasizing confidentiality loss without direct integrity or availability impact.
Why it matters to the business
Applications that rely on Next.js middleware for login enforcement, tenant separation, entitlement checks, or access to private pages may expose sensitive information to unauthenticated users. Even without evidence of active public exploitation or KEV listing, the issue is network-reachable, requires no authentication, has low attack complexity, and affects a widely used web framework, so internet-facing applications using the vulnerable Turbopack path should be prioritized for upgrade.
How an attack unfolds
An attacker first identifies a Next.js application and determines whether protected routes are enforced by middleware rather than by authorization checks inside the route handler or backend service. If the application is built or served with an affected Next.js version using Turbopack and middleware.ts, the attacker sends crafted HTTP requests to routes that normally require authentication. Because the vulnerable Turbopack middleware path does not consistently apply the prior bypass fix, the request can avoid the intended middleware decision and reach the protected route. Successful exploitation is typically observed as unauthenticated HTTP 200 responses, redirects not occurring when expected, or protected page/API content being returned without a valid session.
How to fix it
Upgrade affected Next.js deployments to a fixed release: version 15.5.18 or later for the 15.x line, or version 16.2.6 or later for the 16.x line. Rebuild and redeploy applications after upgrading so the fixed framework code is actually in use. Where immediate upgrade is not possible, reduce reliance on middleware-only authorization by enforcing authorization in route handlers, API handlers, server actions, and backend services; place additional access-control checks at an upstream reverse proxy or identity-aware proxy; and restrict access to sensitive routes until patched. Review package lockfiles and container images to ensure transitive or pinned Next.js versions are not still vulnerable.
How to confirm the fix worked
Confirm the deployed Next.js package version is 15.5.18 or later on the 15.x branch, or 16.2.6 or later on the 16.x branch. Validate both source dependencies and runtime artifacts, including lockfiles, container images, build output, and deployed serverless bundles. Perform negative access tests against routes protected by middleware.ts: unauthenticated requests should be denied, redirected, or challenged, and should not return protected content. If Turbopack is used in build or runtime workflows, specifically retest those workflows after upgrade. Software composition analysis and CI/CD dependency checks should flag Next.js versions from 15.2.0 through versions before 15.5.18, and 16.x versions before 16.2.6, as vulnerable.
Typical attack path
- Identify a public Next.js application and enumerate protected pages or API routes.
- Infer or confirm use of middleware-based access control, especially middleware.ts behavior.
- Send unauthenticated crafted HTTP requests to routes that should require login or authorization.
- Observe whether the application returns protected content instead of redirecting, denying, or challenging the request.
- Automate retrieval of accessible sensitive pages or API responses if the bypass succeeds.
How to detect it
There is no universally reliable exploit string for this issue from the provided advisory, so detection should focus on behavioral evidence of bypass. Review web server, CDN, WAF, application, identity-provider, and API gateway logs for requests to protected routes that returned successful responses without an associated authenticated session, authorization cookie, bearer token, or expected redirect. Compare access logs with application authentication logs to find cases where protected content was served but no corresponding login, session validation, or authorization event occurred. Pay particular attention to spikes in unauthenticated HTTP 200 responses, unusual user-agent rotation, high request rates against private routes, and direct requests to routes normally reached only after login. If historical logs include middleware decision logging, look for requests where middleware did not execute, did not emit expected deny/redirect events, or where downstream handlers served content despite missing middleware authorization context. For forensic review, examine application telemetry around deployments that used affected Next.js versions and Turbopack, and preserve relevant request headers, response codes, session identifiers, and route names for correlation.
What your security team should do
- Inventory internet-facing Next.js applications and identify those using versions 15.2.0 through before 15.5.18, or 16.x before 16.2.6.
- Prioritize applications that use middleware.ts for authentication, authorization, redirects, or route protection, especially where Turbopack is enabled.
- Upgrade to Next.js 15.5.18 or 16.2.6 or later, then rebuild and redeploy all affected applications.
- Add defense-in-depth authorization checks inside protected route handlers and backend services rather than relying solely on middleware.
- Review web access logs for unauthenticated successful access to protected routes during the vulnerable exposure window.
- Create regression tests that verify protected routes cannot be reached without a valid authenticated session.
- Monitor vendor advisories for updates because this issue relates to an incomplete prior fix and may receive additional guidance.
The record
Next.js is a React framework for building full-stack web applications. From 15.2.0 to before 15.5.18 and 16.2.6, it was found that the fix addressing CVE-2026-44575 did not apply to middleware.ts with Turbopack. This vulnerability is fixed in 15.5.18 and 16.2.6.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|---|---|---|
| npm | next | 15.2.0 | 15.5.18 |
| npm | next | 16.0.0 | 16.2.6 |
Related vulnerabilities
- GHSA-26hh-7cqf-hhc6 Next.js has a Middleware / Proxy bypass in App Router applications via segment-prefetch… Same vulnerability
- CVE-2026-44582 Next.js is a React framework for building full-stack web applications. Also affects next
- CVE-2026-44581 Next.js is a React framework for building full-stack web applications. Also affects next
- CVE-2026-44580 Next.js is a React framework for building full-stack web applications. Also affects next
- CVE-2026-44579 Next.js is a React framework for building full-stack web applications. Also affects next
- CVE-2026-44578 Next.js is a React framework for building full-stack web applications. Also affects next
- CVE-2026-44576 Next.js is a React framework for building full-stack web applications. Also affects next
- CVE-2026-44577 Next.js is a React framework for building full-stack web applications. Also affects next