React2Shell and the Question 'Where Do We Run This?'
On December 3, the React team disclosed CVE-2025-55182, an unauthenticated remote code execution vulnerability in React Server Components, rated at the maximum CVSS score of 10.0. The flaw sits in how the server side decodes requests sent to Server Function endpoints, and it affected React 19 versions of the server component packages, along with frameworks that bundle them, most prominently Next.js. Researchers dubbed it React2Shell. Within hours, cloud providers and threat intelligence teams reported exploitation attempts, including by China-nexus groups. CISA added it to the Known Exploited Vulnerabilities catalog on December 5.
The fix itself was routine: upgrade to patched versions of React and the framework. For many organizations, the hard part came before that.
The inventory problem
Ask a security team which applications run on a particular web framework, and the answer often depends on who you ask. Modern web applications are built and deployed in many places:
- product engineering teams’ own cloud accounts and Kubernetes clusters
- managed hosting platforms where marketing, e-commerce and internal tools teams deploy directly
- prototypes and internal tools built quickly and never formally handed over
- commercial products and SaaS services that embed the framework internally
A traditional vulnerability scanner sees hosts and installed packages. It may not see a serverless deployment on a hosting platform, and it can’t see inside a vendor’s service. Software composition analysis sees repositories it’s connected to, which may not include all of them.
The organizations that responded fastest this month had one thing in common: they could answer “where do we run this?” from a single list.
Building that list
Start from code. Searching every source repository the organization owns for dependencies on the affected packages will find most first-party applications. That requires knowing where all the repositories are, which is itself a useful exercise.
Add deployment platforms. Hosting platforms and cloud accounts can list deployed projects. Match those against repositories, and look for deployments that don’t map to any known repository.
Look from the outside. External attack surface data can identify internet-facing applications that show characteristics of the framework. This catches applications nobody listed, which are often the most exposed.
Ask vendors, specifically. For SaaS and commercial products, a general “are you affected?” email produces general answers. Ask whether the product uses React Server Components, which versions, and when it was patched.
Why this keeps happening
React2Shell follows a pattern seen with Log4Shell in 2021 and with several framework flaws since. A widely used component, embedded deep in many applications, gets a critical flaw. Exploitation starts within hours. Organizations discover that their software inventory lists servers and licenses, while the vulnerable component sits inside the applications they build and buy.
Software bills of materials (SBOMs) were promoted after Log4Shell for exactly this reason. Adoption has grown, but many organizations still generate SBOMs for compliance without using them operationally. The real test is whether a security analyst can query them during an incident and get an answer in minutes.
Practical steps before the next one
- Keep a current map of applications to repositories to deployments, with an owner for each. This is the foundation for every framework-level response.
- Generate SBOMs in build pipelines and store them somewhere searchable. Test the search during a quiet week.
- Agree on an emergency upgrade path for web frameworks, including who can approve a production deployment outside normal release cycles.
- Watch internet-facing applications closely after disclosure, using web application firewall rules provided by your providers as a temporary layer while upgrades roll out. Several providers deployed protective rules within a day, which bought time but wasn’t a substitute for patching.
Not only an engineering problem
Framework vulnerabilities are often treated as an application security team’s concern. React2Shell shows why they’re also a cloud governance issue. Applications deployed outside central oversight were the hardest to find and the slowest to patch. A light-touch requirement that any internet-facing deployment be registered, with an owner and a repository, costs very little and pays off the next time someone asks where a particular component is running.