React Server Components DoS patterns and WAF limits
The denial-of-service cases are the easy part, which is rarely a compliment. React Server Components request shapes can look abnormal enough to trip generic signatures, especially where the traffic matches older Server Components attack patterns. Cloudflare’s Managed Ruleset blocks those patterns by default, so existing coverage already catches the obvious flood-style traffic.
That matters because the rules are doing the blunt job here: matching known bad shapes, then blocking them. For the DoS cases, that is usually acceptable. A failed request is cheaper than a saturated origin or an exhausted connection pool.
Server Components request shapes that trip generic signatures
Server Components traffic can be strange enough on the wire to stand out from normal browser chatter. Request bodies, headers, and route patterns used in attacks do not always resemble ordinary app traffic, and that gives generic signatures something to hold on to. The problem is less about cleverness and more about volume and repetition.
Where the attack shape stays consistent, the Managed Ruleset can spot it without much ceremony. That works for DoS traffic because false positives are tolerable if the traffic itself is already malformed or clearly hostile.
Why the Managed Ruleset blocks these by default
Cloudflare has the relevant Managed Ruleset rules set to Block by default, including for Free Managed Ruleset customers. Pro, Business, and Enterprise customers need Managed Rules enabled, but once they are on, the coverage is already there for the disclosed Server Components DoS patterns. The point is not precision. The point is stopping the obvious thing before it eats capacity.
Where WAF mitigation stops being safe
The boundary changes once the issue is no longer just noisy traffic. Middleware bypass, SSRF, and cache poisoning can sit inside ordinary request paths, which means a global WAF rule can end up blocking valid application behaviour along with the exploit. That is the ugly part: safe mitigation is sometimes patching, not filtering.
Several of the disclosed Next.js issues fall into that category. Some cannot be blocked safely in WAF at all. Others can only be handled with narrow rules that understand the specific deployment, adapter, or routing behaviour.
Middleware bypass, SSRF, and cache poisoning need patching or narrow rules
Middleware bypass via segment-prefetch routes or dynamic route parameter injection is the kind of flaw that blends into normal routing logic. WebSocket upgrade handling can open SSRF paths. Cache poisoning in RSC responses, cache-busting collisions, and middleware redirect poisoning all depend on how the application and edge layer interpret requests. A broad managed rule can miss the edge case, or break legitimate traffic that happens to look similar.
That leaves patching as the clean answer for the vulnerable packages. Patched React packages are available in react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack 19.0.6, 19.1.7, and 19.2.6. Patched Next.js versions are 15.5.16 and 16.2.5.
Next.js versions and adapters that change the boundary
The adapter matters because it changes what the edge layer even sees. Cloudflare’s treatment of Vinext and OpenNext on Cloudflare shows that clearly. Vinext strips internal headers such as x-nextjs-data, does not expose Pages Router data-route endpoints, and does not implement the PPR resume protocol. Its latest release is not vulnerable to the disclosed CVEs, and vinext init now requires React 19.2.6 or later. OpenNext on Cloudflare was hardened against the disclosed vectors too, with tests and examples updated.
That is a narrower boundary than a generic WAF can manage. A global rule does not know whether it is protecting a stock Next.js deployment, a stripped-down adapter, or an app that still relies on older routing behaviour. The closer the flaw sits to request semantics, the less safe a blanket block becomes.
Closing the gap without breaking traffic
Patch the framework first. Keep the Managed Ruleset on for the request shapes it already catches, then treat the rest as application fixes or adapter-level hardening. For the Next.js Server Components vulnerabilities that sit in routing, SSRF, or cache behaviour, a WAF rule is not a clean substitute for updating React and Next.js to the fixed versions. A global block that saves one app and breaks three is not a win, it is just a different kind of incident.
