CVE-2025-55184: The Next.js Infinite Loop DoS Hidden in the React2Shell Patch

You got the alert about React2Shell. You read the advisory. You ran npm install next@latest, saw a newer version number in your terminal, and considered the problem solved.

That was the right instinct. But the version you landed on might have shipped with CVE-2025-55184 — a denial of service bug tucked inside the fix itself.

One crafted request. An infinite loop starts. Your server doesn't crash with a 500. It just stops answering. Requests pile up. Memory climbs. From the outside, your app looks alive. From the inside, it's frozen.

The patch that shipped a new problem

When React2Shell (CVE-2025-55182) was disclosed, the Next.js team moved fast. A fix landed quickly, developers updated, and most people moved on.

The problem is that moving fast on a patch sometimes means the patch introduces new surface area. CVE-2025-55184 was found in the versions released to address React2Shell — not in the original vulnerable code, but in the new request-handling logic added to close the RCE.

This is a pattern security researchers call a patch bypass. You're not dealing with two independent bugs. You're dealing with a fix that solved one problem and created another. Developers who updated exactly once to escape the CVSS 10 RCE landed in a window where a DoS attack was possible.

The CVE timeline looks roughly like this: React2Shell disclosed, patch released, CVE-2025-55184 found in the patch, second fix required. If you updated between those two points, you were exposed to the DoS.

What actually happens when this fires

CVE-2025-55184 triggers an infinite loop in the App Router request handling path.

Here's what makes it particularly annoying: Node.js is single-threaded. When something blocks the event loop — like an infinite loop — the runtime can't context-switch away to handle other work. Every request in the queue waits. New requests can't even enter the queue. The process is alive, consuming CPU, and completely useless.

On a managed platform like Vercel, the function timeout eventually kicks in and kills the instance. That's cold comfort when your app has been unresponsive for 30 seconds and the attacker just keeps sending the crafted request to keep resetting the clock.

On a self-hosted Node.js deployment — a VPS, a Railway service, a container — the process hangs indefinitely. You won't see a crash. You won't see a 5xx in your logs. You'll see requests queuing and memory climbing until someone notices and restarts the process. Meanwhile your users see a loading spinner going nowhere.

This is what makes DoS vulnerabilities underestimated. A crash is obvious. A silent hang is not.

There's no authentication required to trigger it. The crafted request hits an App Router route. That's the full requirement. If your app is publicly accessible, the attack surface is your entire domain.

Which versions are affected

If you updated Next.js to escape React2Shell but haven't checked since, verify where you landed.

Check your current version with:

# See exactly what version is installed
npm list next

If your output shows something like next@15.2.2 or next@14.2.33, you're in the affected range.

If you want to check your full dependency surface — not just Next.js, but all packages with known CVEs — Data Hogo does that automatically. Free scan, no card needed.

The fix

Straightforward. Update to a safe version and verify.

# Update to the fixed version
npm install next@15.2.4  # or 14.2.35 for the 14.x line

Then confirm the installed version:

# Verify the update landed
npm list next

Also check your package.json to make sure nothing is pinning you to a vulnerable range:

{
  "dependencies": {
    "next": "15.2.2"
  }
}

A pinned version like "15.2.2" won't update automatically. Change it to "^15.2.4" or just run npm install next@latest if you're comfortable taking the latest release.

One more thing: if you run multiple services or have a monorepo, check each one. It's easy to update the main app and forget about a companion service running an older lockfile.

Why vibe coders are hit harder

The typical vibe coding workflow — scaffold with AI, deploy, move on — leaves a specific gap around dependency maintenance.

When you ship fast and don't revisit the project, your package.json becomes a snapshot of the day you shipped. That's fine for a weekend side project. It's not fine for anything taking real traffic.

CVE-2025-55184 is a good example of why you can't treat "updated to fix X" as "done with security." You patched a CVSS 10 RCE. The follow-on DoS came in the same version window. Both require attention.

The update cadence that actually keeps you safe looks like this: update when a CVE drops, then check again one week later, then follow the changelog for the next minor release. That's three steps that most developers skip after step one.

If your app runs on Next.js App Router and uses Server Functions — which most AI-generated Next.js apps do, because the docs recommend them — you're in the affected population for both CVE-2025-55182 and CVE-2025-55184. Not because you did anything wrong. Because the framework you trust had two bugs in consecutive patches.

TL;DR

• CVE-2025-55184 is a denial of service vulnerability introduced in the Next.js versions that patched React2Shell (CVE-2025-55182).
• A crafted HTTP request triggers an infinite loop, blocking the Node.js event loop and making your app unresponsive to all requests.
• The server doesn't crash — it just hangs silently until restarted.
• Affected: Next.js 14.x before 14.2.35, Next.js 15.x before 15.2.4.
• Fix: npm install next@15.2.4 (or next@14.2.35 on the 14.x line), then verify with npm list next.
• If you updated once for React2Shell and didn't check again, check now — you may have landed in the vulnerable window.
• Run a free scan on Data Hogo to catch this and other CVEs in your dependency tree automatically.