Taking down Next.js servers for 0.0001 cents a pop

👤 Alex Browne    🗓️ 26 Nov 2025    ⏳5 min read

TL;DR

We discovered an unauthenticated DoS vulnerability that crashes a self-hosted Next.js server with a single HTTP request and negligible resources. The attack can be prevented by a reverse proxy that limits request size; rate-limiting alone is not sufficient protection. The vulnerability was initially discovered by our AI AppSec Agent and then confirmed by our in-house team. It has been responsibly disclosed and patched.

Affected software:

• Self-hosted Next.js servers that use middleware (applications hosted on Vercel are not affected)
• Versions <=15.5.4, 14.x, 13.x, and older

Mitigation:

• Upgrade to Next.js version 15.5.5, 16.0.0, or newer
• Or use a reverse proxy configured to limit request size (e.g. nginx with the default client_max_body_size)

Discovery

Funnily enough, we weren't explicitly looking for new vulnerabilities in Next.js at the time of discovery. Instead, we were testing if our AI AppSec Agent could independently find a different, known vulnerability — a recent auth bypass vulnerability in Next.js — without any prior knowledge or hints. To test this, we spun up a demo application running an affected version of Next.js.

For some context, our agent has access to source code and can interact directly with a live application. The agent operates within secure guardrails, but by design has autonomy to explore the entire attack surface. During the course of testing, we noticed the Next.js demo application had crashed. We didn't think much of it at the time and restarted the app.

Later on, we dug into the agent's findings to assess its performance. To our surprise, the findings included not just the vulnerability we were looking for, but also a previously unknown DoS vulnerability! Sure enough, our agent had autonomously executed a PoC script during testing, and that is what caused the application to crash. After further investigation, we confirmed that the vulnerability was present in Next.js itself (rather than just the demo application) and affected the latest version of Next.js at the time.

Details

What our agent discovered and exploited is a vulnerability in the cloneBodyStream function in body-stream.ts. This function copies a streamed request into memory before passing it through to middleware. Since there are no limits on the size of the stream here, a large enough stream will cause the server to run out of memory and crash.

Here's the raw finding from our AI AppSec Agent:

Here's the relevant part of the Next.js source code:

Importantly, while the server copies the entire request into memory, an attacker doesn't need to. An attacker can send an infinite stream of chunks and release each chunk from memory immediately after it's sent. This extreme asymmetry in memory usage is why the attack is so cheap.

(Okay full disclosure — we didn't actually do the math to calculate an attack cost of "0.0001 cents". The point is that it's essentially free. Whatever device you're reading this on has more than enough memory and compute resources. You could pull off the exploit with a single Raspberry Pi or a smart toaster.)

The patch, implemented by the Next.js maintainers on Oct 8 2025 and released a few days later, is pretty straightforward. The cloneBodyStream function now raises an exception as soon as the in-memory buffer exceeds a size limit, which defaults to 10MB.

Impact

The impact is far reaching. Next.js is one of the most popular open source frameworks in the world with over 3M known live deployments. One survey of 2 million Next.js apps found ~55% were self-hosted (80% for enterprises). That said, not all self-hosted Next.js applications are affected. A reverse proxy that limits request size effectively prevents the attack, and a load balancer can reduce impact to some extent by routing requests to a different underlying server when one goes down.

As of time of writing, Vercel has informed us they requested a CVE number but it has not yet been assigned. We have recommended a CVSS v3.1 severity score of  7.5 (high) with the vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. 

Our reasoning: The attack does not require authentication or any complex set up. While we acknowledge that a properly configured reverse proxy or load balancer would reduce the impact of the attack, CVSS guidelines are to assume "the reasonable worst case impact across different deployed environments". Vercel's self-hosting guide did not explicitly recommend a reverse proxy until after our initial disclosure to them. Additionally, we based our recommendation on CVE-2018-12121, a DoS vulnerability in Node.js which "is mitigated by the use of a load balancer or other proxy layer" and was given the same score of 7.5 (high).

Mitigation

A patch was released in version 15.5.5 on Oct 13, 2025. We strongly recommend upgrading to Next.js version 15.5.5, 16.0.0, or newer.

A properly configured reverse proxy can also be used to mitigate the vulnerability. Importantly, the proxy must enforce request size limits; rate limiting alone is insufficient. For example, nginx's default client_max_body_size of 1MB will typically prevent exploitation. Additionally, it's important to ensure the application server is not directly accessible and that all traffic is routed through the proxy. The latest version of Vercel's self-hosting guide provides some additional guidance on reverse proxies.

Note that the following typically do not protect against the vulnerability:

• Next.js's code-based rate limiting
• Next.js's built-in bodyParser.sizeLimit config option
• Other code-based rate limiting approaches such as express-rate-limit and @upstash/ratelimit (these are typically implemented as middleware but the vulnerability occurs before middleware has a chance to run)

How our agent works

Our AI AppSec Agent requires two inputs: source code and a staging endpoint. We use a multi-agent architecture that breaks the codebase down into smaller pieces, analyzes the code for vulnerabilities, and validates findings by executing a PoC script against the staging endpoint. Each underlying agent has access to domain-specific tools and operates in a secure sandbox, so it can't interact with anything outside of the target application.

Next.js is one of the most popular open source frameworks in the world and receives regular scrutiny from Vercel’s engineering team, third-party pentesters, and the open-source community. Our AI agent found a vulnerability that everyone else missed, and chances are we can find a critical vulnerability in your application too. Contact us to learn more.

Disclosure timeline

• 2025-08-07: Disclosed vulnerability privately to Vercel and followed up ~weekly
  
  • Submitted GitHub Security Advisory
  • Emailed responsible.disclosure@vercel.com
• 2025-09-23: Vercel's first response
• 2025-10-13: Vercel's patch‍
• 2025-11-26: Public disclosure and mitigation advice (this blog post)