Our WAF is blocking these POST requests because their payload matches a security filter pattern. We're not able to exempt individual services from this rule. The fix on your side is to modify the request payload your Server Actions send so that it no longer matches the filter, for example by restructuring or encoding the body differently.

The suggested fix isn't actionable for a Next.js app: the POST body in

question is the standard wire format Next.js itself generates for Server

Actions (Next-Action header + framework-encoded body). Application code

has no supported way to restructure or re-encode it — that would require

forking the framework, so this advice cannot be applied by any Next.js

service on Railway.

These are ordinary login/form submissions by real users. Identical

actions submitted from residential IPs succeed; the blocked ones arrived

via datacenter egress IPs, so the rule appears to combine the payload

pattern with source-IP reputation. Our deployment runs patched

next@16.1.6 / react@19.2.3, so CVE-2025-55182 does not apply to it.

Could a human take another look? Ideally the rule should match the actual

exploit signature (malformed RSC payloads) rather than every legitimate

Server Action body coming from a datacenter IP. Also: we are about to

front this service with a reverse proxy on a fixed egress IP — if

per-service exemption is impossible, is an IP-based allowlist an option?

Happy to share the IP and more blocked request IDs.

This is currently locking real users out of production.

The security filter will remain in place, and per-service exemptions and IP-based allowlists are not available for WAF rules. We understand the POST body is generated by the Next.js framework, but the path forward is to ensure the payload your Server Actions produce does not match the filter pattern.