CVE-2026-64643

What it actually does

Affected Next.js applications that use App Router with Server Actions (`use server`) or `use cache` endpoints may expose internal Server Action identifiers through publicly accessible client-side artifacts, such as static JavaScript chunks. An unauthenticated attacker can retrieve those artifacts and enumerate action references that are normally associated with authenticated pages or workflows. The flaw is primarily an information disclosure and reconnaissance issue: it does not inherently grant access to protected data or modify state, but it can reveal callable action IDs and application structure that may be abused if server-side authorization, input validation, or action-level access controls are incomplete.

Why it matters to the business

The main business risk is that attackers can gain insight into backend application functions that were assumed to be hidden behind authenticated pages. This can accelerate targeted probing of account, administrative, checkout, workflow, or data-management features and may expose weaknesses in applications that rely on obscurity rather than explicit server-side authorization. The issue is not currently listed in CISA KEV, has no reported mature public exploitation, and has a low EPSS score, so it is generally lower urgency than active exploitation vulnerabilities; however, internet-facing Next.js applications using Server Actions should still be upgraded promptly because the affected version range is broad and the issue can compound with other design or authorization flaws.

How an attack unfolds

An attacker first identifies a target application built with affected Next.js versions and collects publicly served frontend assets, especially files under `/_next/static/`. They inspect JavaScript chunks for serialized React Server Component or Server Action references and extract action identifiers that correspond to server-side functionality. With those identifiers, the attacker maps which actions may exist behind authenticated pages and may attempt to invoke or probe them using crafted requests, commonly including a `Next-Action` header or related Server Action request structure. If the application properly enforces authorization inside every server-side action, the attacker gains only reconnaissance value. If any action relies on the page being hidden, assumes the caller is authenticated without checking, or has weak input validation, the disclosed identifiers can help the attacker reach and abuse that backend logic.

How to fix it

Upgrade Next.js to a fixed version: use `15.5.21` or later on the 15.x line, or `16.2.11` or later on the 16.x line. Applications on affected 12.x, 13.x, or 14.x releases should migrate to a maintained fixed release rather than remaining on an older vulnerable branch. After upgrading, rebuild and redeploy the application so all generated client and server artifacts are refreshed; clearing CDN and edge caches is recommended to remove previously generated vulnerable static chunks. As defense in depth, ensure every Server Action and cache-backed endpoint performs explicit server-side authentication and authorization checks, validates inputs, and does not rely on route visibility, page access, or unguessable action IDs as a security boundary. Review any sensitive Server Actions for least privilege, rate limiting, CSRF protections where applicable, and safe error handling.

How to confirm the fix worked

Confirm the deployed `next` package version is `15.5.21` or later, or `16.2.11` or later, by checking lockfiles, container images, SBOMs, build logs, and runtime package metadata. Verify the application was rebuilt after the upgrade and that CDN or static asset caches no longer serve pre-upgrade `/_next/static/` chunks. For exposure validation, inspect public JavaScript chunks from the deployed site and confirm they no longer disclose Server Action IDs in the vulnerable manner. Functionally test sensitive Server Actions by attempting unauthenticated and low-privilege requests and confirming the server rejects them based on explicit authorization checks. Also run dependency scanning across repositories and deployment artifacts to identify any remaining Next.js versions from `12.0.0` through `15.5.20` or `16.0.0` through `16.2.10`.

Typical attack path

1. Fingerprint the application as Next.js and identify whether it exposes App Router or React Server Component artifacts.
2. Download public static assets from paths such as `/_next/static/chunks/` and inspect JavaScript bundles.
3. Search client artifacts for Server Action references, action IDs, cache endpoint references, or serialized RSC payload metadata.
4. Correlate discovered action IDs with routes, forms, or application workflows that may normally require authentication.
5. Send crafted requests to candidate routes or endpoints using discovered action identifiers, often testing unauthenticated and low-privilege access.
6. Analyze responses, errors, timing, and status codes to determine whether action-level authorization is missing or inconsistent.
7. If another weakness exists, use the enumerated action IDs to invoke sensitive backend functionality or collect additional application intelligence.

How to detect it

To determine whether this was already exploited, review CDN, reverse proxy, WAF, and web server logs for unauthenticated clients downloading large numbers of Next.js static chunks, especially under `/_next/static/`, followed by POST requests containing Server Action headers or requests to authenticated routes. Correlate suspicious asset scraping with application logs for Server Action execution, authorization failures, validation errors, unusual 4xx/5xx responses, or unexpected unauthenticated invocations. Look for repeated requests with the `Next-Action` header, React Server Component request patterns, or probes that vary action identifiers. Pay particular attention to clients that do not load normal page assets in browser-like order, request JavaScript chunks directly, use automation user agents, or make Server Action POSTs without an authenticated session. If detailed application telemetry exists, audit all sensitive Server Action calls during the exposure window and verify each had an authenticated, authorized principal. Because the vulnerability primarily exposes identifiers rather than producing a unique payload, detection should focus on behavioral correlation: static asset enumeration followed by action probing.

• /_next/static/
• /_next/static/chunks/
• Next-Action:
• RSC: 1
• text/x-component
• __next_f.push
• self.__next_f.push
• use server
• use cache
• POST requests with `Next-Action` header and no authenticated session
• High-volume GET requests for `/_next/static/chunks/*.js` from a single IP
• Unauthenticated POST requests to routes that normally require login

What your security team should do

• Inventory internet-facing and internal applications using Next.js App Router, Server Actions, or `use cache`.
• Prioritize upgrades for applications on Next.js `12.0.0` through `15.5.20` and `16.0.0` through `16.2.10`, especially public applications with authenticated workflows.
• Upgrade to Next.js `15.5.21` or `16.2.11` or later, then rebuild, redeploy, and purge CDN/static asset caches.
• Review Server Actions for explicit authentication and authorization checks; do not rely on hidden pages or action ID secrecy.
• Search web, CDN, WAF, and application logs for unauthenticated static chunk scraping followed by Server Action invocation attempts.
• Add monitoring for unusual `Next-Action` requests, high rates of `/_next/static/chunks/` downloads, and unauthenticated POSTs to routes that normally require login.
• Treat this as a reconnaissance-enabling vulnerability: combine patching with authorization testing of high-risk business actions such as account changes, administrative operations, payments, exports, and data mutations.