Modern Next.js apps execute attacker-controlled input earlier than most teams realize — during framework deserialization, hydration, and Server Action resolution, often before application logging, validation, or auth hooks run.
In several real-world RCE investigations and red-team simulations, repeated 500 Internal Server Errors weren’t “noise” but early execution signals used by attackers to map execution boundaries and refine payloads. In some cases, the last observable 500 occurred right before stable code execution was achieved.
This write-up breaks down:
why deserialization in Next.js is part of execution, not preparation
how silent 500s can indicate pre-handler execution paths
why WAFs and app-level logs frequently miss this class of attacks
where the real attack surfaces live (middleware, RSC, Server Actions, custom servers)
Posting to get feedback from people who’ve seen or investigated similar SSR/RCE behavior in production.
The article is very long and confusing to me. I think there are two main points in there, the stuff around them is more misleading than helpful to me.
The recent React/RSC/Next.js vulnerabilities were just bugs. Adding RSCs added some pretty complex new attack surface, and there were bugs in that. I think being skeptical about new, complex features like this is reasonable. But in the end there was nothing really new about these particular security vulnerabilities. If the framework has bugs in critical parts like this, your apps are insecure until those bugs are fixed or mitigated. I don't get why the author considers this a special case, all frameworks have critical parts that handle how the client data gets to the server. How these works is different, but in the end bugs in there can easily cause security issues.
The second point seems to be that it's easy to misconfigure Next.js middleware. I've read about that before, middleware in Next.js seems to be something that isn't actually middleware as commonly understood. That's a pretty big footgun.
3 comments
[ 5.0 ms ] story [ 21.0 ms ] threadIn several real-world RCE investigations and red-team simulations, repeated 500 Internal Server Errors weren’t “noise” but early execution signals used by attackers to map execution boundaries and refine payloads. In some cases, the last observable 500 occurred right before stable code execution was achieved.
This write-up breaks down:
why deserialization in Next.js is part of execution, not preparation
how silent 500s can indicate pre-handler execution paths
why WAFs and app-level logs frequently miss this class of attacks
where the real attack surfaces live (middleware, RSC, Server Actions, custom servers)
Posting to get feedback from people who’ve seen or investigated similar SSR/RCE behavior in production.
The recent React/RSC/Next.js vulnerabilities were just bugs. Adding RSCs added some pretty complex new attack surface, and there were bugs in that. I think being skeptical about new, complex features like this is reasonable. But in the end there was nothing really new about these particular security vulnerabilities. If the framework has bugs in critical parts like this, your apps are insecure until those bugs are fixed or mitigated. I don't get why the author considers this a special case, all frameworks have critical parts that handle how the client data gets to the server. How these works is different, but in the end bugs in there can easily cause security issues.
The second point seems to be that it's easy to misconfigure Next.js middleware. I've read about that before, middleware in Next.js seems to be something that isn't actually middleware as commonly understood. That's a pretty big footgun.