Topic starter
02/08/2026 12:12 pm
TL;DR: React Server Components in react-server-dom-parcel, react-server-dom-turbopack, and react-server-dom-webpack were affected by CVE-2025-55183 and CVE-2025-55184, adding source code exposure and denial-of-service risk after React2Shell, according to Semgrep. Patch reach is uneven because exploitation depends on specific server-component patterns, making dependency review and fix propagation the real control point.
Editorial analysis by NHI Mgmt Group, based on content published by Semgrep: “New React2Shell Offspring Patched: React Server Components (DoS) and Source Code Exposure”.
Key questions
Q: What should teams do first when a React Server Components flaw affects only some deployments?
A: Start with package-level inventory, because the risk depends on exact React Server Components and Next.js versions rather than the headline framework name.
Q: Why can a source-code disclosure bug matter even when the exploit conditions are narrow?
A: Because even a partial leak can expose inline secrets, connection strings, or operational details that attackers can use to pivot.
Q: How do teams know whether they have fully closed a framework vulnerability chain?
A: They should verify closure by dependency path, not by a single patched version at the top of the stack.
Practitioner guidance
- Review React Server Components package inventory Identify every deployment using react-server-dom-parcel, react-server-dom-turbopack, react-server-dom-webpack, or downstream frameworks such as Next.js that embed them.
- Verify patch propagation across frameworks Confirm that fixed versions are present in each application path, not only in the top-level React version, because related packages may remain vulnerable even after the original issue is remediated.
- Search for inline secrets in server code Inspect server components for connection strings, API keys, and other embedded credentials that could be exposed if a disclosure path is triggered.
Bottom line: These React Server Components flaws do not repeat React2Shell, but they do show how related packages can remain exposed after the headline issue is fixed.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:15 pm
These follow-on flaws show that patching by incident name is not the same as patching by dependency path. A team can resolve the headline vulnerability and still leave related server-component packages exposed because the runtime footprint is distributed across React, Next.js, and variant package names. The practical consequence is that dependency review must become continuous, not event-driven.
A few things that frame the scale:
- Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.
A question worth separating out:
A: Patching React fixes the core vulnerable implementation, but frameworks and plugins that bundle or embed that code also need their own patched releases. If teams update only the base library, downstream packages can still reintroduce the affected path. Effective remediation therefore requires version alignment across the framework, bundler, and any RSC-enabled plugin.
👉 Read our full editorial: React Server Components flaws widen risk beyond React2Shell