CVE-2025-55182: React Server Components unauthenticated RCE via unsafe deserialization
The short version: React Server Components (RSC) — used by modern React and Next.js apps — has an unsafe-deserialization flaw (CVE-2025-55182) in how Server Function endpoints handle request payloads. An unauthenticated attacker who sends a crafted payload can execute code on the server. It scores a perfect 10.0, it's in CISA's KEV catalog, and the affected packages ship in a huge number of applications. If you build on RSC or Next.js, this is patch-and-verify.
At a glance
| Fact | Detail |
|---|---|
| Our severity take | High — in practice and on paper |
| CVSS v3.1 (CNA — Meta) | 10.0 — Critical · AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H (NVD analysis pending) |
| EPSS | 99.56% · 99.9th percentile (2026-07-17) |
| In CISA KEV? | Yes — remediation due 2025-12-12 (added 2025-12-05) |
| Known exploited? | Yes — added to KEV on evidence of exploitation |
| Vulnerability type | CWE-502 deserialization of untrusted data → unauthenticated remote code execution |
| Requires authenticated session? | No — pre-authentication |
| Affected | React Server Components 19.0.0, 19.1.0, 19.1.1, 19.2.0 in packages react-server-dom-parcel, react-server-dom-turbopack, react-server-dom-webpack; and affected Next.js 15.x–16.x builds |
| Fixed in | 19.0.1 · 19.1.2 · 19.2.1 (patch all three packages); upgrade to a fixed Next.js release |
What you need to know
React Server Components let the client invoke "Server Functions" — server-side code reached over HTTP. The vulnerable code deserializes the payloads from those requests unsafely, so an attacker who crafts the right input to a Server Function endpoint can drive execution on the server instead of just passing data.
Deserialization of untrusted data is a well-worn path to remote code execution, and here it needs no authentication. The reach is what sets this one apart: RSC is a foundational piece of the modern React/Next.js stack, so the affected code sits inside an enormous number of applications — many of them public-facing.
- It's pre-authentication and automatable. A crafted HTTP request to the endpoint is enough; no login, no user interaction.
- The blast radius is broad. This isn't one appliance — it's a framework component embedded across countless deployed apps.
How serious we see it
High — the 10.0 is not hyperbole.
Unauthenticated remote code execution in a framework component this widely deployed, already listed in KEV and carrying a near-maximum EPSS, is about as urgent as application vulnerabilities get. The bounded, reassuring part is that the fix is a straightforward dependency bump: patched versions of all three packages exist, and a fixed Next.js release rolls them in. The catch is inventory — the affected package can be a transitive dependency, so the work is finding every app that pulls it in.
Recommendations
Straight from the React team's advisory and CISA:
- Patch now. Upgrade the affected packages to 19.0.1 / 19.1.2 / 19.2.1 (or later), and move Next.js to a fixed release.
- Find every instance. Audit lockfiles and transitive dependencies across all apps — RSC packages can arrive indirectly through Next.js and other tooling.
- Hunt for exploitation. Review server logs for anomalous requests to Server Function/action endpoints and for signs of code execution around the exposure window.
- If you find indicators, respond. Rotate secrets reachable from the app server, and rebuild affected instances where integrity is in doubt.
- Confirm your exposure first. Determine which of your public apps are built on RSC/Next.js and which versions they run.
How BreachRisk sees it
BreachRisk discovers your internet-facing web applications from little more than your domain, fingerprints React/Next.js exposure, and flags assets tied to this KEV-listed, actively exploited flaw — surfaced at the top of your results because it's in KEV. Where testing is authorized, BreachRisk can safely probe the Server Function endpoint for the tell-tale vulnerable response, turning "this app uses React" into a verified, prioritized finding rather than a maybe.
That outside-in view matters most for framework flaws, where the risk hides inside your dependency tree: the exposed app is already mapped, so you can go straight to the upgrade.