Notes from a React2Shell Incident
Reading about outages is easy. Being the one fixing them at 3 AM hits different.
This is not a theoretical write-up. This is what I experienced, what I observed, and what I learned during a real React2Shell incident.
What is React2Shell?
React2Shell is a class of vulnerabilities where frontend code execution can escalate to remote code execution on the server. Under the right conditions, an attacker can go from manipulating React components to executing shell commands.
People still underestimate how serious this vulnerability is. It's not a joke — it's a real security risk that can take down entire systems.
The Incident
It started with alerts. CPU spiking. Memory exhausting. Requests timing out. The usual signs that something is very wrong.
incident timeline
The attack wasn't sophisticated. It was persistent. Wave after wave of requests designed to exhaust resources.
What I Observed
During the incident, several things became painfully clear:
- Logs weren't enough. By the time errors appeared in logs, the damage was already done.
- Averages lie. 5-minute CPU averages looked fine while instantaneous spikes were killing the server.
- Alerts came too late. Threshold-based alerts triggered after the system was already struggling.
- Visibility was limited. I couldn't see what was happening in real-time.
The Attack Pattern
React2Shell attacks typically follow this escalation path:
attack escalation path
The key vulnerability is in how server-side rendering handles untrusted input. If not properly sanitized, user input can become executable code.
Lessons Learned
After the incident, I took some time to reflect on what could have been done better:
1. Real-time observability is essential
You need to see what's happening right now, not what happened 5 minutes ago. This is why I started building Monix.
2. Input sanitization is non-negotiable
Every piece of user input must be treated as potentially malicious. Trust nothing from the client.
3. Rate limiting saves systems
Aggressive rate limiting would have reduced the impact significantly. Don't wait for an incident to implement it.
4. Have runbooks ready
At 3 AM, you don't want to figure out what to do. Document your incident response procedures before you need them.
Why This Matters
React2Shell vulnerabilities are not rare edge cases. They're real, they're exploited, and they can happen to anyone running server-side rendered React applications.
The experience pushed me to:
- Build better monitoring tools (Monix)
- Study system behavior under stress
- Understand security at a deeper level
- Share what I learned so others can be prepared
Closing Thoughts
Incidents are uncomfortable. They expose gaps in knowledge, tooling, and preparation. But they're also the best teachers.
If you're building with React and SSR, take security seriously. Audit your input handling. Monitor your systems. Have a plan.
Because reading about outages is easy. Being the one fixing them at 3 AM hits different.