CVE-2026-44574

What it actually does

Affected Next.js versions 15.4.0 through versions before 15.5.16, and 16.x before 16.2.5, can mishandle dynamic route resolution when middleware is used for authorization decisions. A specially crafted request can use query parameters to influence the dynamic route value ultimately seen by the page while the visible URL path remains unchanged. If middleware authorizes based on the visible path or an expected route shape, but the rendered page receives a different dynamic parameter value, protected content or actions may be reached without the intended authorization check. The flaw is remotely reachable over HTTP, requires low privileges according to the supplied CVSS vector, and primarily affects confidentiality and integrity; availability impact is not expected.

Why it matters to the business

Applications that use Next.js middleware to protect user-, tenant-, account-, project-, or role-specific dynamic routes may expose restricted pages or allow unauthorized actions. The most serious outcomes are disclosure of sensitive business data, cross-account access, unauthorized modification through protected pages, and loss of trust in application-level access controls. Although this issue is not currently listed in CISA KEV, has low EPSS, and has no known public exploit maturity in the provided data, the vulnerability is 89 days old and affects a widely used web framework, so affected internet-facing applications should be upgraded promptly rather than relying on obscurity.

How an attack unfolds

An attacker first identifies a Next.js application with dynamic routes protected by middleware, such as pages where a path segment determines which protected resource is loaded. The attacker authenticates if required, typically as a low-privileged user. They then send requests to protected-looking paths while adding crafted query parameters that alter the dynamic route value processed by the page component or route handler. Because the visible path still appears to satisfy the middleware’s expected authorization logic, the middleware may allow the request, while the downstream page renders content associated with a different dynamic route value. If the application trusts that middleware has already enforced access control, the attacker may view or interact with resources they should not be able to access.

How to fix it

Upgrade Next.js to a fixed release: for the 15.x line, upgrade to 15.5.16 or later; for the 16.x line, upgrade to 16.2.5 or later. If immediate upgrade is not possible, reduce exposure by avoiding authorization decisions that depend only on middleware route matching for dynamic routes, and revalidate authorization inside server components, route handlers, API endpoints, and data access functions using the resolved resource identifier. Reject or normalize unexpected query parameters on sensitive dynamic routes, and ensure that the server-side resource lookup uses only canonical, validated route values. Review applications for dynamic routes where middleware is the sole access-control boundary, especially routes serving sensitive user, organization, administrative, billing, or data-management content.

How to confirm the fix worked

Confirm the installed Next.js version from package-lock.json, pnpm-lock.yaml, yarn.lock, npm ls next, pnpm why next, yarn why next, or the deployed build metadata, and verify it is 15.5.16 or later for 15.x or 16.2.5 or later for 16.x. Exercise sensitive dynamic routes with unexpected query parameters that duplicate, override, or conflict with route parameter names and confirm that middleware and page-level authorization produce the same decision. Add regression tests that attempt to access one protected dynamic resource while supplying alternate dynamic values through query parameters, and verify the response is denied or returns only the authorized resource. Confirm that sensitive data-fetching paths enforce authorization independently of middleware.

Typical attack path

1. Identify a Next.js application using affected framework versions.
2. Find dynamic routes where access is enforced by middleware rather than repeated server-side authorization checks.
3. Authenticate with a low-privileged account if the route requires login.
4. Send requests to protected dynamic paths with crafted query parameters intended to alter the route parameter consumed by the rendered page.
5. Compare responses to determine whether protected content from another dynamic route value is returned.
6. Automate requests against additional dynamic route values to enumerate or modify unauthorized resources.

How to detect it

To assess possible prior exploitation, review HTTP access logs, application request logs, middleware logs, WAF logs, CDN logs, and authorization audit logs for protected dynamic routes. Focus on requests to sensitive dynamic paths that include unexpected query parameters, duplicate names matching route parameters, encoded parameter names, repeated parameters, or values that differ from the visible URL path segment. Investigate successful HTTP 200 or 3xx responses to protected routes where middleware normally records a deny, redirect, or authentication challenge. Correlate suspicious requests with application data access logs to determine whether resources were read or modified outside the requester’s authorized scope. If the application logs both the visible path and resolved route parameters, look for mismatches between those values. Also review low-privileged accounts that accessed unusually many dynamic resource identifiers, especially with query strings present on routes that normally do not require query parameters. There are no public exploit-specific payload strings in the provided data, so detection should rely on behavioral anomalies and application-specific route patterns rather than fixed signatures.

What your security team should do

• Inventory all applications using Next.js and identify those running versions from 15.4.0 to before 15.5.16 or 16.x before 16.2.5.
• Prioritize internet-facing applications and applications with multi-user, multi-tenant, administrative, billing, or sensitive-data dynamic routes.
• Upgrade affected applications to Next.js 15.5.16 or 16.2.5 or later, then rebuild and redeploy production artifacts.
• Review middleware-protected dynamic routes and add server-side authorization checks at the point where protected resources are loaded or changed.
• Add automated tests for route-parameter/query-parameter confusion on protected dynamic routes.
• Search historical web access logs for unusual query parameters on protected dynamic routes, especially requests returning HTTP 200 where similar requests should have been denied.
• Temporarily increase logging around authorization decisions for sensitive dynamic routes until patched deployments are verified.