This is a read on a public disclosure, not a finding of ours. Credit for CVE-2025-55182 belongs to Lachlan Davidson, who reported it to the React team. We write these up because the class of bug outlives the individual CVE.
The facts
- Identifier: CVE-2025-55182, informally “React2Shell”.
- Severity: CVSS 10.0.
- Disclosed: 3 December 2025.
- Affected:
react-server-dom-webpack,react-server-dom-parcelandreact-server-dom-turbopackat 19.0, 19.1.0, 19.1.1 and 19.2.0. - Patched: 19.0.1, 19.1.2 and 19.2.1.
The root cause sits in how React decodes payloads sent to React Server Function endpoints. A crafted HTTP request to such an endpoint achieves remote code execution when React deserializes it. Unauthenticated. No user interaction.
The line worth reading twice, from React’s own advisory: an application may be affected even if it implements no Server Functions of its own, provided it supports React Server Components at all. That is the difference between a bug in code you wrote and a bug in a decoder you inherited.
Why this class keeps landing
Deserialization is what happens when an application rebuilds rich structures out of attacker-controlled bytes. The parser is reachable before your authorisation logic runs, because something has to decode the request before anything can decide who sent it. That ordering is the whole problem.
Framework-level decoders make it worse in one specific way: the vulnerable surface is not in your repository. Nobody on your team wrote it, nobody reviews it, and your threat model probably does not name it. It arrives with the framework and it is exposed on every route the framework serves.
What to check in your own stack
- Inventory every endpoint that accepts a serialised payload your application did not construct: server actions, RPC-style routes, job queues, cache rehydration, session decoding.
- Establish which of those decoders run before authentication. Those are your priority.
- Pin framework versions and know your transitive versions. Applications were exposed here through packages developers did not install directly.
- Treat “we do not use that feature” as a hypothesis, not an answer. Test it.
How we test for it
Bhedan reasons about which routes reach a decoder and proposes candidate payloads for them. A named engineer then attempts the exploit. If it lands, it lands with the call, the payload and the confirming response attached, and it ships as a finding. If it does not, it does not become a paragraph of speculation in your report. It goes in the section that states what we could not prove.
