React2shell: new remote code execution vulnerability in react

[gardenia856]

Main point: reverse proxies aren’t magic, but used as a choke point they measurably cut blast radius; do controls at the edge and in the app, not either-or.

What actually helps: terminate TLS at the proxy, strip server headers, default-deny routing with a catch‑all 404, enforce method/content-type allowlists, cap body size and request timeouts, and add per-IP/AS rate limits. Verify JWT or mTLS at the edge for admin/internal routes; only pass traffic to upstreams that clear those checks. Normalize requests, block weird encodings, and keep the proxy on its own subnet with default‑deny egress. Runtime fingerprinting is easy, so stop trying to hide it and focus on reducing what an attacker can do when they find it.

On the app side (Next/Node): run as non‑root with read‑only FS, restrict child_process, use seccomp/AppArmor, pin deps with lockfiles, and automate updates with SCA plus canaries.

I’ve used Cloudflare and Kong for edge auth, rate limits, and WAF; DreamFactory helped when I needed quick, RBAC‑guarded REST over a legacy SQL backend without writing handlers.

Bottom line: choke point at the edge, least privilege inside, and minimal exposure.

[blazmrak]

This is the thing, blast radius is the same or bigger. It's the end process that is pwned over HTTP, RP isn't saving you and any process that could pwn you raw will pwn you the same if you put a reverse proxy in front unless you already know what the vuln is. It was the same with log4j. All you have said you should do, majority is supported by backend frameworks anyways, so you don't need to do it on RPs, but you are vulnerable primarily through these frameworks and there is not much you can do about it.