CVE-2025-55184 and CVE-2025-55183: what they are, who’s at risk, and how to patch fast

Quick context: why these CVEs showed up now

If you followed the earlier “React2Shell” disclosure (CVE-2025-55182), you already know the pattern: once a major issue is reported, a lot of researchers and defenders start auditing nearby code paths and edge cases. Vercel’s bulletin explicitly calls these “follow-on” findings after the earlier disclosure and stresses that they still require immediate patching.

Two important points that help frame the risk:

1. These two CVEs are not remote code execution. Vercel calls that out directly.

2. They still matter a lot operationally. One can hang your server process (availability impact), and the other can disclose server-side code under certain conditions (confidentiality impact).

What software is affected

Both CVEs target the React Server Components implementation packages:

• react-server-dom-webpack

• react-server-dom-parcel

• react-server-dom-turbopack

and affect a set of React 19.x versions called out by NVD and vendor guidance.

Why Next.js teams should care (even if you never touched “Server Functions”)

In the RSC world, frameworks often provide endpoints and wiring that you didn’t explicitly build yourself. React’s guidance notes that apps can be impacted if they support React Server Components, even if they don’t think they “implemented” specific endpoints.

Vercel also states that these issues affect React 19 and Next.js versions across major lines (13.x through 16.x) depending on how RSC is used.

If you are running any RSC-capable stack (Next.js App Router, or other frameworks/plugins embedding RSC), you should assume you’re in scope until you verify versions.

CVE-2025-55184: pre-auth denial of service via unsafe deserialization

The plain-English problem

CVE-2025-55184 is a pre-auth DoS vulnerability where a crafted HTTP request sent to a “Server Function” style endpoint can trigger behavior that results in an infinite loop, effectively hanging the server process and preventing it from serving future requests.

NVD’s description is very direct: unsafe deserialization of request payloads can cause an infinite loop that hangs the server process.

Why this hurts in real production systems

A DoS bug is not just “the server slows down.” In the RSC case, the impact can be worse because:

• It’s pre-auth: the attacker does not need a login session.

• It can hang a process: if your deployment model is a small number of long-lived Node processes, a hang can starve the service.

• It can cascade: once health checks fail and instances restart, repeated requests can keep pushing the system into instability (restart loops, elevated error rates, queue backlogs).

Even in serverless environments, a DoS-style request can still cause extra resource use and request failures. A motivated attacker can amplify cost and disruption.

What endpoints are typically exposed

Vercel’s bulletin talks about sending malicious requests to App Router endpoints that, when deserialized, can hang the server process and consume CPU.

That phrasing matters: the more your framework exposes “magic endpoints” for server actions or server functions, the more likely you are to have an attack surface that isn’t behind authentication.

How you might notice you’re being hit

Common signals (not unique to this CVE, but consistent with it) include:

• Sudden spikes in CPU with no corresponding traffic increase

• Node process event loop lag and timeouts

• Requests hanging rather than failing quickly

• Autoscaling events that don’t stabilize error rate

• A pattern of repeated requests to RSC-related endpoints, often with unusual payload size/shape

Cloudflare’s threat brief discusses ongoing attention around RSC exploitation patterns and follow-on issues, which is a good reminder to treat this as an “actively studied” area.

Severity snapshot

React’s advisory lists CVE-2025-55184 as high severity with CVSS 7.5.

CVE-2025-55183: source code exposure (in specific configurations)

The plain-English problem

CVE-2025-55183 is an information leak where a specially crafted HTTP request to a vulnerable Server Function can cause the server to return the source code of Server Functions (or compiled server action code, depending on the framework and setup).

NVD describes it as: in specific configurations, a crafted HTTP request may unsafely return the source code of any Server Function.

Vercel frames the impact similarly and adds an important nuance: it can reveal business logic, but it would not expose secrets unless you hardcoded them into the server action’s code.

Why “source code exposure” is still a big deal

Even if you don’t hardcode secrets (and you really shouldn’t), disclosed server code can still be damaging:

• Business logic leakage: pricing rules, fraud checks, internal feature gating, proprietary workflows

• Security weakness discovery: an attacker can read your input validation, auth checks, and edge cases

• Follow-on exploits: source disclosure often turns “hard to find” vulnerabilities into “easy to weaponize” ones

Cloudflare’s write-up adds more color about the kinds of conditions that can lead to “leaking server functions” and why certain patterns around argument handling and validation matter.

Severity snapshot

React’s advisory lists CVE-2025-55183 as medium severity with CVSS 5.3.

The most important question: Am I vulnerable?

Here’s a practical checklist that covers most real teams:

• Are you using React 19 with RSC support?

  • If your stack includes RSC packages (directly or via a framework), you’re in the blast radius. The affected packages and versions are called out by both NVD and Vercel.

• Are you on Next.js App Router (or similar RSC-backed routing)?

  • Vercel’s bulletin specifically discusses App Router endpoints and Next.js affected ranges.

• What versions are you actually running in production?

  • Don’t trust package.json alone. Confirm deployed artifact versions (lockfile resolution, build cache, container layers, etc.).

How to fix: patching guidance that actually works

The priority order

1. Upgrade to patched versions (this is the real fix).

2. Add WAF / edge protections to reduce exposure while rolling out updates.

3. Assume potential disclosure and rotate sensitive material if there is any chance it could have been in code or logs.

Next.js: upgrade to patched releases

React’s official advisory includes concrete Next.js upgrade commands for multiple release lines, pointing to specific patched versions (examples include next@14.2.35, next@15.0.7, and other 15.x/16.x patch versions).

Vercel’s bulletin also provides a “Patched versions” table across Next.js release trains, and notes that Pages Router apps are not affected.

If you are on Next.js, following those exact “release line” upgrades is the safest approach because it aligns with how the Next team ships fixes across maintained versions.

Non-Next.js RSC setups

If you’re using RSC via other frameworks, bundlers, or plugins, the key is still: move off the affected RSC package versions and onto patched ones. Vercel lists examples of other frameworks/plugins that can be affected if they embed or depend on RSC implementations.

Mitigations while you patch (and why they are not enough)

WAF and edge rules

Vercel says it deployed WAF rules to help protect projects hosted on Vercel and emphasizes that WAF rules are an additional layer, not a substitute for upgrading.

If you’re not on Vercel, the equivalent is to use your CDN/WAF (Cloudflare, Fastly, Akamai, etc.) to:

• Block known malicious request patterns tied to RSC endpoints

• Rate limit suspicious clients, especially pre-auth requests

• Add stricter request size limits on relevant routes

This helps, but the vendor messaging is consistent: patching is required.

Rate limiting and circuit breakers at the app layer

DoS bugs punish “infinite patience.” Tighten:

• Per-IP and per-token rate limits (especially unauthenticated)

• Timeouts around server function execution

• Global concurrency caps for server action handlers

• Health checks that detect event loop stalls and remove instances quickly

This won’t remove the vulnerability, but it can reduce blast radius.

Post-patch hygiene: assume the worst (within reason)

If CVE-2025-55183 could have applied, treat it like a “code exposure” incident

Vercel notes secrets are only exposed if hardcoded, but “hardcoded secrets” happens more than teams want to admit, including accidentally (temporary debug keys, copied snippets, or test credentials).

Do a quick sweep:

• Search server action / server function code for anything that looks like secrets (API keys, tokens, private URLs)

• Rotate environment variables that would be damaging if discovered

• Check logs for unusual requests to RSC endpoints and for responses that look like code

Add targeted monitoring around:

• RSC endpoints request volume and error rate

• High CPU with low throughput

• Long request durations and hanging connections

• Unexpected 200 responses with large bodies for endpoints that normally return structured data

What not to do

• Don’t rely on “we’re behind auth” unless you proved it. CVE-2025-55184 is pre-auth by design, and framework routing can expose endpoints you didn’t expect.

• Don’t assume your WAF fully solves it. Even Vercel, while providing WAF protection, still requires upgrading.

• Don’t treat source exposure as harmless. Code disclosure accelerates future attacks, even without secrets.

A simple action plan you can execute today:

1. Inventory where React 19 RSC packages are used (directly or via Next.js / bundler plugins).

2. Upgrade Next.js or your RSC packages to the patched versions for your release line (follow React + framework guidance).

3. Deploy temporary protections (WAF rules, rate limits) during rollout.

4. Rotate secrets if there’s any chance they were hardcoded or could have been disclosed.

5. Add monitoring specifically for RSC endpoints and server action routes.

Closing thought

RSC is not “unsafe,” but it is new enough that patterns are still settling, and attackers are paying attention because the payoff is high: server endpoints that parse complex payloads, often reachable without auth, inside widely deployed frameworks.

CVE-2025-55184 (DoS) and CVE-2025-55183 (source disclosure) are exactly the sort of issues you should expect to see more of as the ecosystem matures. Patch quickly, add guardrails, and assume anything “automatic” in your framework deserves the same threat modeling you would apply to an API endpoint you wrote by hand.