CVE-2026-44573

What it actually does

This is an authorization bypass in Next.js applications using the Pages Router with internationalization enabled and middleware- or proxy-based authorization. In affected versions from 12.2.0 through versions before 15.5.16 and 16.2.5, locale-less requests to `/_next/data/<buildId>/<page>.json` may bypass middleware that would normally enforce access control. If a protected server-side rendered page exposes sensitive values in its JSON data payload, an unauthenticated remote attacker can retrieve that data directly. The impact is confidentiality-focused: the flaw can disclose protected SSR page data, but it does not directly allow code execution, data modification, or service disruption.

Why it matters to the business

Organizations using affected Next.js versions may unintentionally expose data from protected pages, such as user profile details, administrative page content, account metadata, internal dashboard data, or other server-rendered information included in page props. Because exploitation is remote, requires no authentication, and can be performed with simple HTTP requests, internet-facing applications with the vulnerable routing and authorization pattern should be treated as exposed until patched or validated. This issue is not currently listed in CISA KEV and has low EPSS at the time of assessment, but the affected pattern is common enough that security teams should prioritize review of public Next.js applications that use Pages Router, i18n, and middleware-based access checks.

How an attack unfolds

An attacker first identifies a target application running Next.js and determines whether it uses the Pages Router data endpoint pattern. They obtain or infer the application build ID, commonly from rendered page source, `__NEXT_DATA__`, or references to `/_next/static/<buildId>/` assets. The attacker then identifies protected page routes, such as account, dashboard, billing, admin, or profile pages. Instead of visiting the localized protected page URL that would normally trigger middleware authorization, the attacker sends direct locale-less requests to `/_next/data/<buildId>/<protected-page>.json`. In vulnerable configurations, middleware does not run for that unprefixed data route, so the server returns the SSR JSON payload for the protected page without enforcing the intended authorization checks. The attacker can automate requests across likely page names and parse returned JSON responses for sensitive data.

How to fix it

Upgrade Next.js to a fixed version: 15.5.16 or later for the 15.x line, or 16.2.5 or later for the 16.x line. Applications on affected versions from 12.2.0 onward should move to a supported fixed release. After upgrading, redeploy all affected applications so the patched routing and middleware behavior is active. As a defense-in-depth measure, ensure authorization is enforced in server-side data-fetching logic as well as middleware, avoid placing sensitive data in page props unless strictly required, and review i18n routing assumptions. If immediate upgrade is not possible, add temporary edge, proxy, or WAF rules that block unauthenticated access to sensitive `/_next/data/<buildId>/<protected-page>.json` paths, including locale-less variants, and verify that middleware or equivalent authorization controls apply consistently to both page routes and data routes.

How to confirm the fix worked

Confirm the deployed Next.js version is 15.5.16 or later, 16.2.5 or later, or otherwise not in the affected range. Validate exposure by selecting protected Pages Router routes and testing unauthenticated requests to both the normal page URL and the corresponding `/_next/data/<buildId>/<page>.json` URL without a locale prefix. The data endpoint should not return protected JSON to an unauthenticated or unauthorized user; expected outcomes are redirect, 401, 403, or a sanitized non-sensitive response. Repeat testing across configured locales and representative protected pages. Review application behavior after deployment to ensure build IDs changed as expected and that CDN or edge caches are not serving previously exposed JSON responses.

Typical attack path

1. Identify a public web application running an affected Next.js version.
2. Confirm that the application uses Pages Router data routes by looking for `/_next/data/` or `__NEXT_DATA__` references.
3. Extract or infer the active Next.js build ID from page source or static asset URLs.
4. Enumerate likely protected routes such as dashboard, account, profile, billing, settings, or admin pages.
5. Send unauthenticated locale-less requests to `/_next/data/<buildId>/<page>.json`.
6. Look for HTTP 200 JSON responses where the corresponding page should require authentication or authorization.
7. Parse the returned SSR JSON for sensitive business, user, or application data.
8. Repeat across additional route names, locales, and deployment build IDs.

How to detect it

Review CDN, WAF, reverse proxy, load balancer, and application access logs for direct requests to `/_next/data/` JSON endpoints, especially requests without an authenticated session, without a normal page navigation referrer, or targeting protected route names. Prioritize HTTP 200 responses to locale-less paths such as `/_next/data/<buildId>/dashboard.json` where the equivalent localized page should require login. Compare successful JSON requests against authentication logs to determine whether the requester had a valid session at the time. Look for route enumeration behavior, including many `/_next/data/` requests from the same source IP across common protected page names, multiple 404/403/200 combinations, or requests with scripted user agents. If logs include response size, investigate unusually large JSON responses from protected data routes. Also inspect CDN caches for stored `/_next/data/` responses that correspond to protected pages.

• GET /_next/data/
• POST /_next/data/
• /_next/data/
• /_next/data/*/admin.json
• /_next/data/*/dashboard.json
• /_next/data/*/account.json
• /_next/data/*/profile.json
• /_next/data/*/settings.json
• /_next/data/*/billing.json
• /_next/data/*/users.json
• /_next/data/*/reports.json
• /_next/data/*/manage.json
• /_next/data/*/console.json
• /_next/data/*/internal.json
• /_next/data/*/private.json
• /_next/data/*/protected.json
• __NEXT_DATA__
• /_next/static/

What your security team should do

• Inventory internet-facing Next.js applications and identify those using Pages Router, i18n, and middleware- or proxy-based authorization.
• Prioritize patching affected applications to Next.js 15.5.16 or 16.2.5 or later.
• Test protected routes by directly requesting locale-less `/_next/data/<buildId>/<page>.json` endpoints without authentication.
• Add temporary WAF, CDN, or reverse-proxy controls for unauthenticated access to protected `/_next/data/` JSON routes if patching cannot be completed immediately.
• Review SSR page props for sensitive information and move authorization checks into server-side data-fetching or backend APIs where possible.
• Search historical CDN, WAF, reverse proxy, and application logs for unauthenticated successful requests to protected `/_next/data/` JSON endpoints.
• Check whether any returned JSON data may have included regulated, customer, financial, administrative, or internal business information.
• Invalidate CDN caches and redeploy after patching to prevent stale vulnerable JSON responses from remaining accessible.