It’s surprising how a tiny behaviour in React Server Components turned into attackers being able to run code inside Node.   
  
A crafted Flight frame reaches hydration, React treats it as a trusted server action, rebuilds the function reference, and executes it. No authentication in front of that step.  
  
So far, what’s clear is that anything on **React Server DOM 19.0.0 → 19.2.0**, or **Next.js App Router** that isn’t patched, or really any SSR setup parsing Flight frames from outside, is likely exposed.  
  
And if someone actually tries this practically…They could end up pulling **secrets/env variables**, tweaking files or runtime configs, finding ways to **move internally**, and even tampering with **CI builds** if SSR executes during pipelines.  
  
For anyone with public-facing RSC endpoints, this doesn’t feel like something you wait to fix in the next sprint. Patching sooner seems less stressful than reading a post-incident summary later.   
  
Meanwhile, watching for unexpected processes or outbound traffic around hydration paths seems reasonable until people share stronger defences.  
  
Also, if you want to double-check remediation steps, you can read this piece - [CVE-2025-55182: React2Shell RCE Demands Immediate Security Action ](https://strobes.co/blog/react2shell-cve-2025-55182-rce/)  
  
Is anyone here testing detections for malicious Flight data? It would be great to hear what’s proving effective in real environments before this appears in incident reports.

Has anyone dug into React2Shell - CVE-2025-55182 yet?