React RSC Flaws: Stop DoS and Code Leaks With AI

A lot of security teams still treat “framework vulnerabilities” as a developer problem. That’s a mistake—especially when the bug is pre-auth, trivially triggerable over HTTP, and sits on the request path that powers revenue.

React Server Components (RSC) just gave us a clean example: newly patched issues can cause denial of service (DoS) and even source code exposure in certain Server Function scenarios. What makes this more than a routine “update your dependencies” story is the pattern behind it: a prior critical RSC flaw (CVE-2025-55182) was reportedly weaponized, and the community then found adjacent bypass and variant paths.

If you’re running React in production (directly or through a framework stack that pulls in RSC packages), this is the moment to combine fast patching with AI-powered threat detection. The patches reduce the blast radius; AI helps you spot the exploit attempts you didn’t know to look for—especially when attackers are iterating.

What happened: three RSC bugs, two outcomes

Answer first: The newest React RSC vulnerabilities fall into two practical risk buckets—service availability (DoS) and confidentiality (source code exposure). Both can be triggered via crafted HTTP requests to Server Function endpoints under the right conditions.

React released fixes for issues in the react-server-dom-* packages that enable:

• DoS via unsafe deserialization leading to an infinite loop
• DoS via an incomplete prior fix (a variant of the first bug)
• Information leakage that can return the source code of Server Functions

Here are the CVEs and what they mean operationally:

DoS: infinite loop hang from unsafe deserialization

CVE-2025-55184 (CVSS 7.5) is a pre-auth DoS. The failure mode matters: it’s not “high CPU for a moment.” It’s an infinite loop that hangs the server process, potentially preventing the server from handling future HTTP requests.

CVE-2025-67779 (CVSS 7.5) is described as an incomplete fix for the above. This is the part that should make your incident response muscles twitch: attackers don’t stop at the first patch. They look for alternate paths, slightly different payload shapes, different endpoint configurations—anything that reopens the door.

Info leak: source code exposure from crafted requests

CVE-2025-55183 (CVSS 5.3) can cause a vulnerable Server Function to return the source code of any Server Function—but exploitation depends on application specifics. The requirement called out by React is important: it needs a Server Function that explicitly or implicitly exposes an argument that has been converted into a string.

That means this may not hit every app equally. It also means you shouldn’t dismiss it. Plenty of real apps stringify inputs for logging, tracing, error messages, feature flags, or dynamic routing.

A practical rule: if a Server Function takes user-controlled input and ever turns it into a string (directly or indirectly), assume it’s worth auditing.

Who’s affected and what to patch (fast)

Answer first: If you use React Server Components in production, you should patch react-server-dom-parcel, react-server-dom-turbopack, and/or react-server-dom-webpack to the fixed versions immediately.

The affected versions called out are:

• CVE-2025-55184 and CVE-2025-55183: 19.0.0, 19.0.1, 19.1.0, 19.1.1, 19.1.2, 19.2.0, 19.2.1
• CVE-2025-67779: 19.0.2, 19.1.3, 19.2.2

React’s recommended fixed versions are:

• 19.0.3
• 19.1.4
• 19.2.3

Why “patch now” is the right call in December

Late December is when teams run lean, change windows get weird, and “we’ll do it in January” starts sounding reasonable. Attackers love that.

If you’re in a freeze period, treat this like a safety patch:

• Roll forward the specific react-server-dom-* dependency versions
• Deploy behind a staged rollout (canary) if you can
• Add temporary compensating controls (WAF rules, rate limits) while you validate

This isn’t alarmism. It’s a pattern we see repeatedly: public patch → researcher scrutiny of adjacent code → variants → exploitation at scale.

Why these flaws are perfect use-cases for AI-driven detection

Answer first: DoS and data leakage attacks often look like “normal HTTP traffic” until you correlate subtle signals across endpoints, payload shapes, and error patterns. That correlation is exactly where AI threat detection and anomaly detection outperform static rules.

Most organizations already have logs. The gap is turning logs into answers fast enough to matter.

AI can spot “variant hunting” after a headline CVE

When a high-profile vulnerability drops, attackers tend to:

1. Replay known proof-of-concepts
2. Mutate parameters and payload formats
3. Search for endpoint-specific quirks
4. Iterate until they bypass mitigations

Traditional detection struggles because the signatures keep changing. A decent AI detection pipeline can instead model baseline request behavior and flag deviations such as:

• Sudden spikes in request volume to Server Function endpoints
• Repeated requests with high-entropy or unusual serialized payloads
• An uptick in timeouts, hung worker processes, or aborted connections
• Rare response sizes or content types that don’t match normal Server Function outputs

The key is to treat “post-CVE traffic” as a temporary high-risk period and tighten anomaly thresholds.

AI helps you detect DoS attempts before customers notice

A pre-auth DoS doesn’t need a botnet if it can hang your process. A handful of crafted requests can be enough—especially if you’re running a limited pool of Node workers.

AI-assisted detection works well here because it can combine app and infrastructure signals:

• Application metrics: event loop lag, request latency, increased 5xx, stalled responses
• Runtime signals: worker restarts, memory growth patterns, CPU pinned without throughput
• Edge signals: retries, unusual burst shapes, repeated payload similarity across IPs

Done right, your system should alert on the early indicators: “this endpoint started behaving differently,” not “we’re down.”

AI can catch source code exposure as a data leak pattern

Source code exposure isn’t always obvious in the moment. The response might return a 200, the client might be a “normal browser,” and the payload might be chunked.

An AI-driven data leak detection approach focuses on:

• Response body classification (does this look like JavaScript/TypeScript source?)
• Unexpected token patterns common in code (imports/exports, function signatures, JSX markers)
• Unusual response sizes from endpoints that normally return small JSON payloads
• Access pattern anomalies (one client enumerating multiple Server Functions quickly)

This matters because source exposure is a follow-on enabler: once an attacker sees internal logic, they find business logic bugs, hidden endpoints, authorization gaps, and secrets handling mistakes.

Practical defensive playbook for React RSC (beyond “update”)

Answer first: Patch first, then harden. The best outcomes come from combining dependency updates, runtime guardrails, and AI-assisted monitoring.

1) Patch and verify what’s actually deployed

Dependency drift is real—especially across micro-frontends, internal packages, and CI caches.

A simple, high-value checklist:

• Confirm the deployed react-server-dom-* versions in production artifacts
• Identify every service exposing Server Function endpoints
• Validate that the fixed versions are present in the lockfile and the built bundle
• Run a targeted smoke test that hits Server Function routes under load

2) Add guardrails that blunt pre-auth DoS

Even after patching, DoS defenses pay off because attackers will try other methods next week.

Implement:

• Per-endpoint rate limits (Server Function endpoints should rarely be “unlimited”)
• Request body size limits (keep them strict; increase only with a business reason)
• Timeouts and circuit breakers at the reverse proxy and app layer
• Worker isolation (don’t let one hung request starve the entire pool)

If you can’t do all of that, do rate limiting plus timeouts. It’s the fastest win.

3) Reduce the chance of source exposure conditions

For CVE-2025-55183-style scenarios, focus on the specific exploitation prerequisite: stringifying user-controlled arguments.

Audit patterns like:

• Logging raw input values (especially if they’re later included in errors)
• Converting complex objects to strings for tracing
• Returning debug values from Server Functions in non-production builds
• Using user input to dynamically choose server-side modules/functions

A strong engineering stance: no user-controlled input should ever influence which server code is selected or reflected without strict validation.

4) Operationalize AI detections into response, not dashboards

AI threat detection only produces leads if it’s wired to action. I’ve found teams get the most value when they decide upfront what happens when the model fires.

For this class of risk, define automated responses like:

• Temporarily throttle or block offending clients at the edge
• Isolate the affected service (reduce blast radius)
• Trigger an incident workflow when two signals align (e.g., anomaly score + elevated timeouts)
• Capture forensic context automatically (full request metadata, sampling payload hashes)

The goal is simple: contain first, analyze second.

“People also ask” questions your team will get

Answer first: Expect questions from product and engineering about urgency, exploitability, and whether AI is “required.” Here are clear answers you can reuse.

Are these React RSC vulnerabilities exploitable without authentication?

Yes for the DoS class. The DoS issues are described as pre-auth, meaning an attacker doesn’t need to log in if the endpoint is reachable.

Does source code exposure mean attackers get the entire repository?

Not automatically. The info leak is scoped to Server Function source code exposure under specific conditions. Still, leaking even a single sensitive Server Function can expose authorization logic, internal API calls, and validation assumptions.

If we patch, do we still need AI monitoring?

Yes. Patching fixes the known CVEs; monitoring catches:

• Exploit attempts during the patch window
• Variant attempts against adjacent code paths
• DoS attempts using other techniques (flooding, resource exhaustion)
• Unexpected data exposure that isn’t tied to a known CVE

That’s the difference between being “not vulnerable” and being “hard to take down.”

Next steps for security leaders (and a fast self-check)

If you want a quick self-check, ask two questions:

1. Can we identify every internet-reachable Server Function endpoint in under an hour? If not, your exposure management needs work.
2. Can we detect and respond to unusual Server Function traffic in minutes, not days? If not, you’re relying on customer complaints as monitoring.

React RSC vulnerabilities are a sharp reminder that modern application security is now runtime security. In this “AI in Cybersecurity” series, we keep coming back to the same point: AI anomaly detection is most valuable where the attacker’s behavior is the signature—and DoS plus data leaks are exactly that.

If you’re patching RSC this week, consider using the same change window to add two lasting improvements: AI-assisted detection for Server Function anomalies and an incident playbook that can throttle abuse automatically. The next framework headline won’t wait for your January backlog—so what will your monitoring catch before your users do?