Next.js HTTP request deserialization can lead to DoS when using insecure React Server Components
Published 28 Jan 2026 · Updated 10 Sept 2026
Affected packages
- Affected
- >=13.0.0 <15.0.8
- Fixed in
- 15.0.8
npm install next@15.0.8- Affected
- >=15.1.1-canary.0 <15.1.12
- Fixed in
- 15.1.12
npm install next@15.1.12- Affected
- >=15.2.0-canary.0 <15.2.9
- Fixed in
- 15.2.9
npm install next@15.2.9- Affected
- >=15.3.0-canary.0 <15.3.9
- Fixed in
- 15.3.9
npm install next@15.3.9- Affected
- >=15.4.0-canary.0 <15.4.11
- Fixed in
- 15.4.11
npm install next@15.4.11- Affected
- >=15.5.1-canary.0 <15.5.10
- Fixed in
- 15.5.10
npm install next@15.5.10- Affected
- >=15.6.0-canary.0 <15.6.0-canary.61
- Fixed in
- 15.6.0-canary.61
npm install next@15.6.0-canary.61- Affected
- >=16.0.0-beta.0 <16.0.11
- Fixed in
- 16.0.11
npm install next@16.0.11- Affected
- >=16.1.0-canary.0 <16.1.5
- Fixed in
- 16.1.5
npm install next@16.1.5Details
A vulnerability affects certain React Server Components packages for versions 19.0.x, 19.1.x, and 19.2.x and frameworks that use the affected packages, including Next.js 13.x, 14.x, 15.x, and 16.x using the App Router. The issue is tracked upstream as CVE-2026-23864.
A specially crafted HTTP request can be sent to any App Router Server Function endpoint that, when deserialized, may trigger excessive CPU usage, out-of-memory exceptions, or server crashes. This can result in denial of service in unpatched environments.
Is GHSA-h25m-26qc-wcjf 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
Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.