NAW rsc_exploit_attempt false-positive on a NON-RSC React Router 7 app (not Next.js)

JavaScript
,
1

Hi all,

Flagging what looks like an over-broad match in the NAW rsc_exploit_attempt rule (the React2Shell / CVE-2025-55182 heuristic). It’s blocking legitimate traffic to our app, and (unlike the existing reports which are all Next.js) our app doesn’t use React Server Components at all. So this may be a useful data point for narrowing the rule.

Related existing threads (all Next.js RSC), for context — looks like a recurring family of false positives:

The Error

error.message="could not complete HTTP request to instance: legacy hyper error:
client error (SendRequest), caused by: error from user's Body stream,
caused by: blocked by NAW: rsc_exploit_attempt"
proxy ord [error] request.url="/"

App: tr-pilot-admin (org: trolleyrelay), primary region syd, block seen at the ord edge. (Same stack runs in production as tr-admin.) During the block window we see ZERO app-side traffic, not even a request in our own logs, which is how we localised it to the NAW edge rather than our app.

Why this is a false positive, we’re not RSC, and not the request shape the rule targets

Our app is a React Router 7 app in standard framework (SSR) mode, NOT Next.js, and NOT using React Server Components:

  • No React Server Components anywhere. Navigation is React Router’s single-fetch .data loader protocol, not the RSC Flight protocol.
    • no react-server-dom-* package installed (only an OPTIONAL, unmet peer of @react-router/dev, we don’t provide it);
    • no RSC bundler plugin (@vitejs/plugin-rsc not installed);
    • server rendering is the classic renderToPipeableStream from react-dom/server, not the RSC Flight renderer;
    • no ‘use server’ / server-component directives in our source.
  • No React server-action headers. The React2Shell exploit rides RSC/server-action headers (next-action in Next.js, rsc-action-id etc. elsewhere). Our requests carry none of these, we don’t use React server actions at all.
  • On the React side we’re also on the latest React 19.2.x (well past the CVE fixes), but the point is we’re structurally off the RSC code path entirely, so the CVE can’t apply regardless of version.

So there’s no RSC Flight traffic for the rule to legitimately match. It appears to be triggering on the request shape of one specific client, the Shopify mobile admin app’s embedded webview making single-fetch .data navigations (desktop browsers on the same app are never blocked).

Impact
We’re a Shopify embedded app. Merchants using the Shopify mobile app get intermittently dropped out of our embedded UI to a login/error state, because their requests are killed at the edge before reaching us. Desktop is fine.

Ask
Could the rsc_exploit_attempt matcher be narrowed so it stops catching non-RSC React Router traffic (or, if a rollback like the rsc_flight_chunk_reference thread is easier, that works for us too)? A React-Router-not-Next.js app tripping this rule is hopefully a useful signal that the heuristic is over-matching beyond the RSC frameworks it’s meant to cover.

Happy to provide more captured request samples, exact headers, timestamps, etc., just let me know what’s most useful.

Thanks!

Stephen