Explore all React2Shell and framework vulnerability guides →
A web application firewall can reduce exposure by filtering requests, but it does not replace patching a React2Shell-affected deployment. React's advisory explicitly says not to depend on temporary hosting-provider mitigations. Treat the firewall configuration and the installed application fix as separate controls, with separate evidence and owners.
A blocked request is evidence about that request
Vercel's React2Shell bulletin describes WAF rules as an additional defense against known patterns and states that they cannot guarantee protection against every attack variant. It also documents iterative rule updates. That is a reason to keep vendor guidance and the application remediation work current, rather than interpreting an enabled rule as a permanent answer to the underlying dependency problem.
For your own review, distinguish a rule being available, a rule being enabled and a rule applying to the traffic path in question. A dashboard can show the first two while leaving a hostname, environment or routing path outside the intended scope. Record the relevant configuration and ask the platform owner to explain how requests reach the application.
Map the paths that should be covered
- The public customer domain, including the canonical hostname and any alternate aliases that still serve the application.
- Preview and staging domains, which may have different access controls or deployment histories.
- Provider-generated deployment URLs and any origin access that the infrastructure owner permits.
- Separate APIs, microfrontends or services with their own projects and firewall configuration.
- Documented exceptions for integrations or automation, including who owns them and when they should expire.
Review this inventory through configuration and ordinary authorized requests. You do not need to run an RCE payload to discover that a forgotten preview exists or that its access policy differs from production. Where a protective setting cannot be verified, record the uncertainty and resolve it with the responsible provider or engineer.
Keep mitigation and remediation tickets connected
Use a mitigation ticket to track the rule, affected routes, activation time, monitoring owner and any compatibility impact. Use a linked remediation ticket to track the vendor advisory, required upgrade, build, rollout and deployed artifact. This lets the team act quickly without losing the work that removes the vulnerable component.
For example, a team may enable a protective rule while preparing an application update. Its correct status is mitigation active, patch pending. After the replacement artifact serves all intended traffic and the remaining deployment inventory is resolved, the team can record the patch verification separately. Neither status is a statement about whether the earlier exposure was exploited.
Check availability as well as the security setting
Test normal sign-in, form submissions and server-side application journeys after changing controls. Investigate unexpected blocks with the request context and platform logs, taking care not to publish sensitive values. Keep narrowly justified exceptions under review. Avoid solving a compatibility problem by silently disabling protection for a broad set of routes.
Interpret scans performed behind the firewall carefully
Run MyPentest on a site you own or are authorized to assess for its supported website checks. If the firewall prevents a check from reaching the application, that can limit what the scan establishes. Review findings, unchecked items and coverage details. MyPentest's detection of React2Shell is unverified here, and an empty report behind a WAF is not proof that the underlying React deployment is patched.