Next.js: Cache confusion of response bodies for requests with bodies containing invalid UTF-8 byte sequences
Published 22 Jul 2026 · Updated 10 Sept 2026
Affected packages
- Affected
- >=13.0.0 <15.5.21
- Fixed in
- 15.5.21
npm install next@15.5.21- Affected
- >=16.0.0 <16.2.11
- Fixed in
- 16.2.11
npm install next@16.2.11Details
Impact
A server-side fetch with a request body may return a cached response body from a different request to the same URL but different body. Confidential data in the POST's response body would then leak to unauthorized requests. Though the request itself will not be deduped.
This is only an issue when receiving request bodies with a content type charset other than UTF-8. For example, the UTF-16 byte sequences for 삃삃 and 섄섄 in the request body would share the same cache.
Workarounds
If you cannot upgrade, consider only making fetch requests with UTF-8 bodies (default in Next.js). Applications using Pages Router are not vulnerable.
Is GHSA-4633-3j49-mh5q in any of your client repos?
Checking one package by hand is fine. Checking it across forty client projects is not. NPMscan reads the lockfiles in every GitHub repo you pick, finds each project with an affected next, and gives you the command that fixes it.
References
- Linkgithub.com/vercel/next.js/security/advisories/GHSA-4633-3j49-mh5q
- Linkgithub.com/vercel/next.js/pull/96008
- Linkgithub.com/vercel/next.js/commit/025bf4a5f7b47fb7758c4ebf1c931a61c451c082
- Packagegithub.com/vercel/next.js
- Linkgithub.com/vercel/next.js/releases/tag/v15.5.21
- Linkgithub.com/vercel/next.js/releases/tag/v16.2.11
Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.