CVE-2026-64647

What it actually does

CVE-2026-64647 is an information disclosure flaw in Next.js server-side fetch caching. In affected versions, a server-side fetch request that includes a body and uses a non-UTF-8 content-type charset can incorrectly reuse a cached response body from another request sent to the same URL with a different request body. The request itself is still sent, but the application may receive and return the wrong cached response body. If the cached response contains confidential data, an unauthorized requester can receive data generated for a different request or user. The issue affects Next.js 12.0.0 through 15.5.20 and 16.0.0 through 16.2.10, and is fixed in 15.5.21 and 16.2.11.

Why it matters to the business

Affected applications may accidentally expose user, account, transaction, or internal API response data to the wrong requester when vulnerable server-side fetch patterns are present. The practical risk depends on whether the application uses cached server-side POST fetches with request bodies and non-UTF-8 charsets, which makes exploitation more conditional and higher complexity. There is no CISA KEV listing, no known ransomware association, low EPSS score, and no public exploit maturity reported, but Next.js is widely used for internet-facing applications, so organizations should still patch promptly and review sensitive server-side fetch behavior.

How an attack unfolds

An attacker first identifies a Next.js application running an affected version and looks for a route or server action that causes the server to make a cached fetch request using POST or another request method with a body. The vulnerable pattern requires the server-side fetch to use the same destination URL while varying the request body, and the body must be interpreted with a charset other than UTF-8. The attacker then crafts requests using non-UTF-8 encoded bodies that can collide in the vulnerable cache behavior. If a sensitive response body from another request has been cached under the same effective cache key, the attacker’s request may receive that cached response instead of the response corresponding to their own body. Successful exploitation can disclose confidential response contents, such as user-specific data, account details, application state, or backend API output, without requiring the attacker to directly access the victim’s request.

How to fix it

Upgrade Next.js to a fixed version: 15.5.21 or later for the 15.x line, or 16.2.11 or later for the 16.x line. Applications on affected 12.x, 13.x, or 14.x releases should upgrade to a supported fixed release. After upgrading, rebuild and redeploy the application so the patched Next.js runtime is actually in use. As interim mitigation, avoid caching server-side fetches that use request bodies, especially POST requests, and explicitly set `cache: 'no-store'` or equivalent behavior for sensitive backend calls. Normalize or reject request bodies using non-UTF-8 charsets where business requirements allow. Do not cache responses containing user-specific, account-specific, authentication-derived, or otherwise confidential data unless the cache key safely includes all authorization and request-body attributes.

How to confirm the fix worked

Confirm dependency versions in package manifests and lockfiles show Next.js 15.5.21 or later, or 16.2.11 or later. Verify the deployed runtime matches the patched package version, not only the source repository. Review server-side code for `fetch()` calls that send a request body and rely on default or explicit caching behavior. Pay particular attention to POST requests, server actions, route handlers, and data-fetching utilities that call the same backend URL with different request bodies. Test sensitive routes by sending distinct non-UTF-8 request bodies, such as UTF-16 encoded payloads, and confirm that each response corresponds only to its own request and never returns another request’s response body. Inspect responses and application logs for cache hits on body-bearing server-side fetches where the request body differs.

Typical attack path

1. Identify an internet-facing application built with an affected Next.js version.
2. Find an application endpoint that triggers server-side fetch requests with a request body.
3. Determine whether the server-side fetch response is cached and whether different request bodies are sent to the same URL.
4. Send requests using a non-UTF-8 content-type charset, such as UTF-16, to influence the vulnerable cache behavior.
5. Cause or wait for a sensitive response body from another request to be cached for the same fetch URL.
6. Send a colliding request body and receive a cached response body associated with a different request.
7. Extract confidential data from the mismatched response and repeat against other affected routes if possible.

How to detect it

To determine whether exploitation may already have occurred, review HTTP access logs, application logs, edge proxy logs, WAF logs, and backend API logs for requests with non-UTF-8 `Content-Type` charsets, especially UTF-16, UTF-16LE, UTF-16BE, or other uncommon encodings. Correlate repeated requests to the same application route or backend fetch URL where the request bodies differ but the returned response size, response body hash, user-specific identifiers, or cache metadata are identical. Look for user reports or application errors indicating mismatched account data, unexpected records, or responses not matching submitted input. Review server logs around sensitive POST-backed workflows for cache hits or reused response artifacts. If request/response body logging or safe response hashing is available, compare whether the same response body was returned across different request bodies, sessions, users, or authorization contexts. Also inspect source and build artifacts to determine whether vulnerable Next.js versions were deployed during the time window under investigation.

• Content-Type: application/json; charset=utf-16
• Content-Type: application/json; charset=UTF-16
• Content-Type: application/json; charset=utf-16le
• Content-Type: application/json; charset=UTF-16LE
• Content-Type: application/json; charset=utf-16be
• Content-Type: application/json; charset=UTF-16BE
• charset=utf-16
• charset=UTF-16
• charset=utf-16le
• charset=UTF-16LE
• charset=utf-16be
• charset=UTF-16BE
• next@12.
• next@13.
• next@14.
• next@15.5.20
• next@16.2.10
• "next": "12.
• "next": "13.
• "next": "14.
• "next": "15.5.20"
• "next": "16.2.10"

What your security team should do

• Prioritize upgrading all affected Next.js applications to 15.5.21, 16.2.11, or a later supported version.
• Inventory internet-facing Next.js applications and identify those using versions 12.0.0 through 15.5.20 or 16.0.0 through 16.2.10.
• Search code for server-side `fetch()` calls that include a request body and do not explicitly disable caching.
• Disable caching for sensitive server-side requests, especially those returning user-specific or authorization-dependent data.
• Add application-layer validation to reject unexpected non-UTF-8 charsets unless explicitly required.
• Review logs for unusual POST traffic using non-UTF-8 charsets, repeated requests to the same endpoint with different bodies, or reports of users receiving mismatched data.
• If exposure is confirmed, treat it as a potential data disclosure incident and assess what cached response bodies may have been returned to unauthorized requesters.