React2Shell (CVE-2025-55182): React and Next.js Remediation Guide

React2Shell is a critical unauthenticated remote-code-execution flaw in React Server Components. Use this current guide to identify affected packages, select the latest patched release in each supported line, validate the upgrade, and investigate possible exposure without relying on hosting-provider mitigations alone.

Back to Blog
(Updated )
3 min read
Illustration depicting the React2Shell critical security vulnerability, showing a fragmented React logo surrounded by red warning indicators and cybersecurity shield elements against a dark digital background representing srv infrastructure under threat

Reviewed August 15, 2026. React2Shell is the name commonly used for CVE-2025-55182, an unauthenticated remote-code-execution vulnerability in the React Server Components protocol. The React team rated it CVSS 10.0 and advised immediate upgrades. Next.js tracks its downstream App Router impact as CVE-2025-66478.

The practical response is straightforward: determine whether the vulnerable React Server DOM packages are present, move every affected application to the latest patched version in its supported release line, test the resulting build, and investigate any system that may have been exposed before patching.

What React2Shell affects

The original React advisory identifies versions 19.0, 19.1.0, 19.1.1, and 19.2.0 of react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack as vulnerable. The corresponding fixed releases were 19.0.1, 19.1.2, and 19.2.1. Applications that do not use a server and do not use tooling that supports React Server Components are outside the scope described by that advisory.

Do not decide exposure from the top-level react version alone. Frameworks and bundlers can include or depend on the vulnerable server packages. Inspect the resolved dependency tree and the framework mode actually deployed.

npm ls react react-dom react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack next
npm audit --omit=dev

Next.js impact and current patch guidance

The Next.js advisory says the downstream issue applies to App Router applications processing attacker-controlled requests. The React advisory now lists patched versions for multiple Next.js 14, 15, and 16 release lines and notes related denial-of-service and source-code-exposure updates. Because those floors changed after initial disclosure, copy the version for your release line from the current advisory rather than from an old social post or scanner message.

If a supported upgrade is unavailable for an obsolete or canary deployment, treat migration to a supported stable line as incident-response work. A web application firewall or hosting-provider rule can reduce exposure, but the React team explicitly says not to depend on provider mitigations instead of updating.

Immediate response checklist

  1. Inventory production artifacts. Check the deployed lockfile, container image, serverless bundle, and software bill of materials—not just a developer laptop.
  2. Patch by supported release line. Update React Server DOM packages and affected frameworks together so peer dependencies remain coherent.
  3. Build and test in isolation. Exercise Server Actions, authentication, uploads, caching, and error paths before promotion.
  4. Replace immutable artifacts. Rebuild containers or deployment bundles from a reviewed lockfile; do not patch a running directory by hand.
  5. Confirm the runtime result. Re-run dependency inspection inside the deployed artifact and record the exact resolved versions.

Investigate possible exposure

A version match establishes vulnerability, not compromise. Review request logs, process creation, outbound connections, unexpected file changes, newly created credentials, and cloud or deployment audit trails for the exposure window. Preserve evidence before cleanup. If suspicious activity is found, isolate the workload and follow the organization’s incident-response process.

Rotate credentials based on evidence and blast radius. Prioritize secrets available to the application process: deployment tokens, database credentials, cloud workload identities, signing keys, and third-party API keys. Rebuilding without addressing exposed credentials can leave an attacker with continuing access.

Validation and prevention

  • Make lockfile and production-artifact dependency scans release gates.
  • Track framework support windows and remove unsupported release lines.
  • Run applications with least-privilege service identities and restricted outbound access.
  • Keep an asset inventory that maps public applications to repositories, owners, runtimes, and deployment artifacts.
  • Record the advisory URL and resolved versions in the change ticket for later audit.

ITECS can help organizations validate public application exposure and build a repeatable remediation process through its managed cloud services. Product-specific patch decisions should still follow the current upstream advisories.

Primary sources

continue reading

More ITECS blog articles

Browse all articles

About Brian Desmot

The ITECS team consists of experienced IT professionals dedicated to delivering enterprise-grade technology solutions and insights to businesses in Dallas and beyond.

View full profile and articles

Share This Article

Continue Reading

Explore more insights and technology trends from ITECS

View All Articles