CVE-2025-67779: The Next.js DoS Fix That Needed a Fix

You saw the alert. React2Shell, CVSS 10, remote code execution, update immediately. You ran npm install next@latest, deployed, and moved on. Security handled. Back to shipping.

Then a second CVE dropped. Then a third.

CVE-2025-67779 is the vulnerability found in the patch for CVE-2025-55184, which was itself found in the patch for React2Shell (CVE-2025-55182). Three CVEs in a chain. If you updated once and stopped watching, there's a real chance you're still vulnerable to a denial of service attack — and you feel safe because you patched.

That's the worst kind of exposed.

The three-CVE chain, in plain English

If you missed the full story of React2Shell, here's the short version: a researcher found that Next.js App Router would deserialize incoming data from Server Functions without properly validating it. An attacker could send one crafted HTTP request and execute arbitrary code on your server. CVSS 10. No authentication needed.

Vercel and the Next.js team moved fast. A patch landed quickly. Most developers updated and closed the tab.

But patching a complex deserialization bug is hard. You fix the obvious attack vector, ship it, and then someone finds the edge case your fix didn't cover. Then someone finds the edge case in the fix for the edge case.

That's exactly what happened here:

1. React2Shell (CVE-2025-55182): Remote code execution via malformed Server Function requests. CVSS 10. Patched quickly.
2. CVE-2025-55184: A denial of service vulnerability found in the patched versions. Carefully crafted requests could trigger an infinite loop in the App Router's request handling, freezing your server. Addressed in a follow-up fix.
3. CVE-2025-67779: A denial of service variant found in the fix for CVE-2025-55184. The second patch closed most of the attack surface but left a residual path open. This is the one that made it into a full CVE record.

Each fix was genuine. Each one addressed a real attack path. And each one left something on the table.

What CVE-2025-55184 patched — and what it left open

After React2Shell, the Next.js team hardened how the App Router handles requests to Server Functions. The patch added validation logic to reject requests that didn't meet certain criteria before processing began.

That validation logic had a flaw. CVE-2025-55184 was a denial of service vulnerability — not RCE, but still serious. An attacker who knew the shape of a valid App Router request could craft input that passed the new validation checks but then caused the request handler to loop without terminating.

The result: the Node.js process would peg CPU at 100%, stop responding to legitimate traffic, and eventually need a restart. On a serverless platform like Vercel, this translates to functions timing out, cold starts stacking up, and your users seeing errors while your bill climbs.

The second patch tightened the validation logic further. It closed the infinite loop path. But it introduced a slightly different edge case — a variant that an attacker could still trigger under specific conditions.

That variant became CVE-2025-67779.

What changed in CVE-2025-67779

CVE-2025-67779 is a denial of service vulnerability in the Next.js App Router affecting versions that implemented the CVE-2025-55184 fix but hadn't yet applied the final remediation.

The attack surface is similar: a crafted HTTP request targeting App Router endpoints. The specific mechanism is a variant of the same incomplete validation path — different enough from CVE-2025-55184 that it needed a separate CVE record, similar enough that the final fix addresses both.

From the attacker's perspective, the vulnerability is straightforward to exploit if you know what version of Next.js a target is running. The version range is narrow — between the first DoS patch and the final fix — but that window existed in production for long enough that many apps went through it without a subsequent update.

The impact is DoS, not RCE. That means your data isn't directly at risk. But a frozen server is still a business problem: downtime, failed deployments, and the kind of incident that wakes someone up at 3am.

The version that actually fixes everything

Here's the full picture — three CVEs, one table:

Notice that the "Fixed in" column for CVE-2025-67779 and CVE-2025-55182 are identical. Next.js 14.2.35+ and 15.2.4+ are the versions that close all three vulnerabilities in the chain.

If you updated to a version between the first React2Shell patch and 14.2.35 (or 15.2.4), you closed the RCE but may have landed in the DoS window. The final fix pulled all of these threads together in one release.

One version to remember: 14.2.35 on the 14.x line, 15.2.4 on the 15.x line.

Why you might have missed this update

Patch fatigue is real. And the way security information flows through the developer ecosystem makes the second and third patches structurally easy to miss.

When React2Shell dropped, it was everywhere. GitHub security advisories, Twitter threads, Hacker News front page. You couldn't miss it. That's how CVSS 10 RCE vulnerabilities work — the signal is loud.

CVE-2025-55184 and CVE-2025-67779 are DoS vulnerabilities. Important, but not CVSS 10 RCE. They didn't get the same amplification. If you follow security through tweets and changelog skimming, you probably saw React2Shell and didn't see the follow-ups.

There's also a psychological component. You patched. You did the right thing. That action registers as "done" in your mental task queue. You're not looking for a follow-up because you already handled it.

This is the exact failure mode that makes patch chains dangerous. The first patch provides real protection against the first vulnerability. That protection creates a false sense of completeness. The second and third vulnerabilities inherit the credibility of the first fix.

The OWASP guidance on vulnerability management addresses this specifically: a single patch event is not a remediation posture. You need a process that monitors for follow-up advisories, not just first disclosures.

How to check and fix right now

First, find out what version you're actually running:

npm list next

Or if you want a quick grep against your manifest:

cat package.json | grep '"next"'

The package.json version might show a semver range like ^14.2.10. That doesn't tell you what's actually installed. Use npm list next to see the resolved version on disk.

If you're below 14.2.35 on the 14.x line, or below 15.2.4 on the 15.x line, update:

# Update to latest stable
npm install next@latest
 
# Or pin to a specific safe version on the 14.x line
npm install next@14.2.35

After updating, verify the installed version:

npm list next

Then redeploy. If you're on Vercel, a new deployment picks up the updated dependency automatically once you push. If you're self-hosting in Docker, rebuild your image.

# Verify the resolved version before you ship
npm list next
# next@14.2.35 or next@15.x.x — either is fine

If you want to catch this kind of thing automatically — across your full dependency tree, not just Next.js — Data Hogo scans your repo for known CVEs, outdated packages, and vulnerable patterns in one pass. Free scan, no credit card.

TL;DR

• React2Shell (CVE-2025-55182) was a CVSS 10 RCE in Next.js App Router. Patched quickly. Huge coverage.
• CVE-2025-55184 was a denial of service flaw found in the React2Shell patch. Got much less attention.
• CVE-2025-67779 is a DoS variant found in the CVE-2025-55184 fix. The third link in the chain.
• If you updated after React2Shell but didn't track follow-up advisories, you may still be in the vulnerable window.
• Next.js 14.2.35+ and 15.2.4+ close all three vulnerabilities. That's the target version.
• Run npm list next to see what you're actually running. Then update and redeploy.
• Patch fatigue is real. The second and third CVEs in a chain are the ones that hurt you.