CVE-2026-44575

What it actually does

This is an authorization bypass in affected Next.js App Router applications. Applications running Next.js 15.2.0 through versions before 15.5.16, and 16.x before 16.2.5, can expose protected App Router pages when authorization is enforced only through middleware or proxy-based route matching. Specially crafted React Server Component transport URLs, including .rsc and segment-prefetch route variants, may resolve to the same protected page while not matching the intended middleware rule. The result is unauthenticated, network-accessible disclosure of protected page content. The CVSS impact is confidentiality-focused: an attacker does not need credentials or user interaction, but the primary impact is unauthorized read access rather than code execution or service disruption.

Why it matters to the business

Organizations using affected Next.js versions for authenticated portals, admin interfaces, dashboards, customer-facing applications, or internal tools may unintentionally expose protected data to unauthenticated users. Depending on what the protected pages contain, this could lead to leakage of customer information, business records, account data, operational dashboards, or other sensitive content. Although this is not currently listed in CISA KEV and no public exploit maturity is reported in the supplied data, the issue is remotely exploitable, low complexity, and affects a widely used web framework, so exposed applications should be prioritized for upgrade and review.

How an attack unfolds

An attacker first identifies a Next.js App Router application with routes that appear protected by middleware or proxy authorization checks. They then request transport-specific variants of those routes, such as React Server Component .rsc URLs or segment prefetch URLs, rather than the normal browser-facing page URL. In affected versions and configurations, those alternate route forms can be routed to the same protected page content without triggering the middleware rule that would normally enforce authentication or authorization. If successful, the attacker receives protected server-rendered content or data embedded in the response without logging in. The attack is fully remote, requires no valid account, and can be performed by sending crafted HTTP requests directly to the application.

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. If possible, upgrade to the latest stable Next.js release rather than only the minimum fixed version. Review authorization design so that sensitive data access is enforced in the page, layout, route handler, server action, API, or backend data-access layer, not only in middleware or proxy match rules. Treat middleware as an additional control, not the sole authorization boundary. As a temporary mitigation until upgrade, restrict access to sensitive routes at an upstream reverse proxy, WAF, identity-aware proxy, or application gateway using rules that account for .rsc and prefetch route variants. Disable or tightly control exposure of sensitive App Router pages where authorization depends exclusively on middleware matching.

How to confirm the fix worked

Confirm the deployed Next.js version is 15.5.16 or later on the 15.x branch, or 16.2.5 or later on the 16.x branch. Inspect package manifests, lockfiles, container images, build logs, and runtime artifacts to ensure the fixed version is what is actually deployed. Test representative protected App Router routes while unauthenticated using normal URLs and transport variants such as .rsc and segment-prefetch requests; all should return a login redirect, 401, 403, or equivalent denial rather than protected content. Validate that authorization is enforced in server-side application logic or backend access checks, not solely through middleware matcher patterns. Review edge/CDN/proxy behavior to ensure it does not cache or serve protected .rsc or prefetch responses to unauthenticated users.

Typical attack path

1. Identify a public Next.js application using the App Router.
2. Find routes that appear to require authentication or authorization, such as dashboards, account pages, admin pages, or private application areas.
3. Generate alternate transport-specific route variants for those paths, including .rsc and segment-prefetch-style requests.
4. Send crafted unauthenticated HTTP requests to those variant URLs.
5. Compare responses against expected unauthenticated behavior, looking for protected content, serialized server component data, or route payloads returned without redirects or access-denied responses.
6. Automate enumeration of protected routes if one bypass pattern succeeds.

How to detect it

To determine whether this was already exploited, review HTTP access logs from the application, CDN, WAF, reverse proxy, and edge runtime for requests to protected or normally authenticated routes using React Server Component or prefetch transport variants. Focus on unauthenticated requests that include .rsc in the URL, segment-prefetch path components or query values, RSC-related headers, or Next.js router prefetch headers, especially when the response status was 200 rather than 302, 401, or 403. Correlate suspicious requests with session logs to determine whether the requester lacked a valid authenticated session at the time. Compare response sizes and cache statuses: successful bypass attempts may have response sizes similar to authenticated protected pages and may include server component payload content. Investigate repeated enumeration patterns across many protected paths from the same source IP, user agent, ASN, or request fingerprint. Also review CDN cache logs for any protected .rsc or prefetch responses cached with public or shared cache behavior.

• .rsc
• segment-prefetch
• RSC: 1
• Next-Router-Prefetch: 1
• Next-Router-State-Tree
• ?_rsc=
• text/x-component
• 200 response to unauthenticated request for protected .rsc URL
• 200 response to unauthenticated request containing segment-prefetch

What your security team should do

• Inventory internet-facing and internal applications using Next.js App Router and identify versions in the affected ranges: 15.2.0 to before 15.5.16, and 16.x before 16.2.5.
• Prioritize upgrading exposed applications and applications serving sensitive data to Next.js 15.5.16, 16.2.5, or later.
• Review all routes where access control depends on middleware or proxy matchers and move critical authorization checks into server-side route, page, API, or data-access code.
• Add regression tests that request protected routes through normal page URLs, .rsc variants, and prefetch-style variants while unauthenticated.
• Search web, CDN, WAF, reverse proxy, and application logs for unauthenticated requests to protected paths containing .rsc or segment-prefetch indicators.
• Ensure protected RSC and prefetch responses are not cached publicly by CDN or reverse proxy layers.
• Consider temporary WAF or reverse-proxy blocks for suspicious unauthenticated .rsc and segment-prefetch requests to sensitive paths until upgrades are complete.