React2Shell: The Next Struts2-Style Bug Parade?

The React2Shell bug evokes déjà vu regarding lessons in "Abstract" versus "Concrete" Risk, potentially extending to B2B sales dynamics that remain partially unexplored.

During the 2010s, Apache Struts made a comparable architectural decision: concentrating framework behavior around OGNL, an expression language deployed extensively throughout. OGNL permeated Struts with minimal visible safeguards. The codebase lacked clear module boundaries, "here be dragons" API warnings, or robust type/visibility barriers. Innocuous helper functions like translateVariables() sat beside normal framework operations, prepared to execute passed code.

This period witnessed successive OGNL-driven RCE vulnerabilities in Struts 2. The recurring pattern: user-controlled data—ubiquitous in web frameworks—reached code paths executing it as expressions. Major breaches, including Equifax, resulted.

React2Shell represents a comparable situation. React Server Components introduced Flight protocol and Server Functions: mechanisms serializing client→server calls and deserializing them into function invocations and object structures. This vulnerability constitutes an unsafe-deserialization/server-side prototype pollution bug in decoding logic, permitting unauthenticated attackers to send crafted payloads executing server code.

CVE-2025-55182: Current Status

• CVSS 10.0 rating (rarely assigned correctly)

• Affects default React 19 RSC configurations and frameworks including Next.js App Router, React Router RSC, Waku

• Active wild exploitation by multiple threat actors, including China-nexus groups; added to CISA's KEV catalog

• CVE-2025-55182

This represents "Concrete Risk": specific CVE, functional exploits, scanning IPs, patch deadlines. Universal comprehension exists. Teams scramble patching.

The Abstract Risk That Preceded This Bug

The "Abstract Risk" preceding this bug merits greater attention: embedding powerful language/protocol interpreters within request pipelines determining server code execution.

In Struts, "Abstract Risk" meant OGNL expression language wired directly into request handling, with user-controlled strings feeding it from multiple directions (tags, error messages, parameters). The framework facilitated "data" to "code" slippage intentionally.

React's "Abstract Risk" involves:

• Flight protocol functioning as mini-serialization language for modules, functions, complex objects—not merely JSON

• Server Functions occupying privileged stack positions representing application logic

• Decoding logic implicitly expanding object properties, hooking module loading and function invocation, where failures prove catastrophic

Concrete vs Abstract: The Core Distinction

Point releases patch "Concrete Risk" (React 19.0.1/19.1.2/19.2.1 with matching Next.js fixes should be applied). Yet "Abstract Risk" questions remain harder, more significant, hopefully surviving current news cycles:

Should "introducing new interpreter/protocol in request paths" receive P0 architectural risk classification as OGNL, JNDI, template engines should have? Or do teams treat individual CVEs as isolated surprises?

Teams consistently repair provable concrete bugs—PoC exists, KEV entry exists, patches exist, alignment occurs. Few teams possess capacity saying, "This entire pattern threatens before CVE emergence" or "Shipping this commits us to decade-long whack-a-mole absent strong boundaries."

That represents "Abstract Risk": architectural choices' latent costs potentially surfacing only through headlines later. Currently, even post-CVE, the React team likely perceives risk as abstract. They believe risk suppressed; theoretical objections seem secondary. Their official notice addresses "Abstract" considerations minimally.

What This Means Going Forward

No definitive React trajectory recommendations exist here without deeper code knowledge. However, React2Shell provides additional evidence: whenever powerful interpreters or serialization protocols hide "behind-scenes" supporting developer ergonomics, history suggests eventual remote code execution emergence.

What Follows?

AppSec and platform engineering must better recognize these patterns pre-CVE accumulation, communicating how "Abstract" becomes "Concrete." Succeeding here demands storytelling, metaphor, battle selection—not pure technical expertise.

Following Twain's rhyming history: developers likely won't confront "Abstract Risk" comprehensively, necessitating management of numerous "Concrete Risks" throughout coming years.