CVE-2026-64642

What it actually does

CVE-2026-64642 is an authentication bypass in Next.js 16.0.0 through 16.2.10. Under a specific configuration—applications using the App Router, built with Turbopack, with middleware or proxy-based authentication, and an i18n configuration containing exactly one locale—specially crafted HTTP requests can cause authentication middleware/proxy checks to be bypassed. The result is unauthorized access to routes or application resources that were intended to be protected by middleware-enforced authentication. The vulnerability primarily affects confidentiality, with potential limited integrity impact if protected pages expose state-changing functionality.

Why it matters to the business

Affected applications may allow unauthenticated users to access protected web pages, APIs, dashboards, account areas, or administrative workflows that rely on Next.js middleware/proxy logic for access control. This can lead to data exposure, unauthorized business actions, compliance issues, and loss of trust. The currently reported EPSS score is low and the issue is not listed in CISA KEV, with no public exploit maturity indicated, but because the flaw is network-exploitable without credentials and affects authentication, remediation should be prioritized for internet-facing Next.js applications that match the vulnerable configuration.

How an attack unfolds

An attacker first identifies a public Next.js application running a vulnerable 16.0.0 through 16.2.10 version and determines whether it uses App Router, Turbopack-built output, middleware or proxy-based authentication, and a single-locale i18n configuration. The attacker then sends crafted HTTP requests to protected routes in a way that triggers the vulnerable routing/i18n/middleware interaction. If successful, the request reaches the protected route without the expected authentication middleware or proxy enforcement. The attacker can then view restricted content or interact with protected application functionality as an unauthenticated user, limited by what the underlying route itself permits beyond the bypassed middleware check.

How to fix it

Upgrade Next.js to version 16.2.11 or later. Prioritize applications that meet all of the vulnerable conditions: Next.js 16.0.0 through 16.2.10, App Router, Turbopack build, middleware/proxy-based authentication, and config.i18n.locales containing a single locale. If immediate upgrade is not possible, reduce exposure by enforcing authentication inside route handlers, server actions, API handlers, and backend services rather than relying solely on middleware/proxy checks; add edge/WAF rules only if a reliable exploit pattern is known; restrict access to sensitive routes through upstream identity-aware proxies where feasible; and avoid single-locale i18n middleware assumptions until upgraded. Rebuild and redeploy after upgrading, because vulnerable behavior may be embedded in generated application output.

How to confirm the fix worked

Confirm that all deployed Next.js applications are running Next.js 16.2.11 or later by checking package manifests, lockfiles, build output metadata, container images, and deployed artifacts. Review next.config.js or equivalent configuration for i18n.locales containing exactly one locale. Verify whether App Router and Turbopack are used in production builds. Identify all routes whose authentication depends on middleware or proxy logic, then perform unauthenticated negative tests against protected pages and APIs, including locale-prefixed, normalized, encoded, and otherwise unusual path variants. A fixed deployment should consistently return the expected deny behavior, such as 401, 403, or redirect to login, for every unauthenticated request to protected resources. Also confirm that rebuilt artifacts were deployed after the dependency upgrade rather than only updating source files.

Typical attack path

1. Identify a Next.js application exposed to the network.
2. Fingerprint the application for Next.js 16.0.0 through 16.2.10 behavior or deployment artifacts.
3. Probe for App Router routes protected by middleware or proxy-based authentication.
4. Test whether the application appears to use i18n routing with a single configured locale.
5. Send crafted requests targeting protected routes to trigger the middleware/proxy authentication bypass condition.
6. Access protected content or functionality that should have required authentication.
7. Automate requests against additional protected paths if the bypass is reliable.

How to detect it

To determine whether exploitation already occurred, review web server, CDN, reverse proxy, WAF, and application access logs for unauthenticated requests that received successful responses from routes normally requiring login. Focus on the period since deploying Next.js 16.0.0 or later through the upgrade to 16.2.11 or later. Correlate successful 200/3xx responses to protected paths with missing or invalid session cookies, missing authorization headers, anonymous user context in application logs, or failed login activity from the same source shortly before successful access. Examine logs for unusual path variants against protected routes, including locale-prefixed paths, duplicate slashes, encoded characters, path traversal-like normalization attempts, and requests that differ only by casing or URL encoding. If application audit logs exist, look for actions performed without an authenticated principal or with an unexpected anonymous/default identity. No public threat actor attribution, KEV listing, or mature exploit activity is currently indicated in the provided data, so detection should emphasize behavioral anomalies and access-control violations rather than known actor infrastructure.

What your security team should do

• Inventory internet-facing Next.js applications and identify those running versions 16.0.0 through 16.2.10.
• Prioritize upgrades to Next.js 16.2.11 or later for applications using App Router, Turbopack, middleware/proxy authentication, and a single i18n locale.
• Add regression tests that verify protected routes cannot be reached without authentication, including path normalization, locale, and encoded-path variants.
• Move critical authorization checks into server-side route handlers or backend services so middleware bypasses cannot grant access by themselves.
• Review access logs for unauthenticated successful responses to normally protected routes during the exposure window.
• Increase monitoring on sensitive routes until all affected applications are upgraded and redeployed.
• Document whether each application is vulnerable, not vulnerable due to configuration, or remediated by upgrade.