Understanding the React2Shell (CVE-2025-55182) Vulnerability

Update 2 – December 4, 2025: A working proof-of-concept exploit for React2Shell has been published and independently validated against a default Next.js configuration. This changes the practical severity of CVE-2025-55182. Details below have been updated accordingly.

A critical vulnerability was recently disclosed in React Server Components, widely referred to as React2Shell and tracked as CVE-2025-55182. It carries a maximum severity rating of CVSS 10.0. The issue is rated as high severity and affects certain versions of React used by frameworks such as Next.js. Although early analyses focused on different aspects of exploitability, the essential question for most engineering and security teams is straightforward. When is this vulnerability exploitable and what action should we take now.

The CVE record notes that “a pre-authentication remote code execution vulnerability exists in React Server Components versions 19.0.0, 19.1.0, 19.1.1, and 19.2.0, including the react-server-dom-parcel, react-server-dom-turbopack, and react-server-dom-webpack packages. The vulnerable code unsafely deserializes payloads from HTTP requests to Server Function endpoints.”

This post provides a clear summary of what is known today, how exploitability varies across configurations, and what development teams should do to reduce risk. It also explains how different proof of concept implementations behave in real environments and why certain exploits work only in specific setups.

Why CVE-2025-55182 (React2Shell) Matters

React remains one of the most widely used JavaScript libraries on the web, and Next.js is the leading full stack framework for React deployments. Versions 13 through 16 introduced React Server Components (RSC) as a default or recommended pattern. As a result, the server side RSC plumbing is now present in a significant share of modern React applications, even when teams are not explicitly adopting RSC features.

React2Shell targets this RSC “Flight” protocol. Because it enables pre-authentication remote code execution (RCE), any server exposing vulnerable endpoints is at risk. The combination of a maximum severity score, broad adoption, and the subtlety of RSC exposure in some deployments makes CVE-2025-55182 a high-priority vulnerability for engineering and security teams to understand and evaluate.

Which React and Next.js Versions Fix React2Shell (CVE-2025-55182)?

React and Next.js published security fixes in the following versions:

• React: 19.0.1, 19.1.2, 19.2.1
• Next.js: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7

Applications running earlier versions that use React Server Components should plan to upgrade as soon as possible. The official React and Next.js advisories remain the authoritative reference for patch information.

Note on CVE identifiers: Next.js initially published its own CVE entry (CVE-2025-66478), but this has since been rejected by MITRE as a duplicate of CVE-2025-55182. React2Shell is therefore tracked under a single CVE ID.

Upgrade Compatibility: The Averlon Remediation agents verified that there are no known breaking changes when upgrading to the patched versions of these packages.

Which Frameworks Besides Next.js Are Affected?

Although most early analysis focused on React and Next.js, several other frameworks and bundlers also depend on the vulnerable RSC packages. These projects adopted RSC support independently, so exposure is not limited to Next.js. Each of these projects implemented RSC support independently, which means they may include the same vulnerable code paths even without using Next.js.

The following frameworks and bundlers are known to include or depend on the affected RSC packages:

• React Router
• Waku
• @parcel/rsc
• @vitejs/plugin-rsc
• rwsdk
• Next.js (covered separately)

Projects using these tools may include the vulnerable code paths if they are using or building with RSC features. Teams should monitor maintainer advisories for updates or patches and evaluate whether their application path uses RSC at build or runtime.

Is React2Shell (CVE-2025-55182) Exploitable in Default Configurations?

A central question has been whether the vulnerability is exploitable in a default Next.js application created through official tooling. Additionally, a publicly available proof of concept has also been published and independently validated to achieve remote code execution against a default Next.js application using React Server Components.

This confirms that default deployments include not only the vulnerable code paths, but also an exploitable surface under standard configurations. Exposure can still vary based on how an application is hosted or routed, but the availability of a working PoC significantly elevates practical risk for unpatched systems.

Static sites generated with Next.js are not vulnerable, since they do not use React Server Components or expose the server side Flight protocol.

What Engineering Teams Should do Right Now

Upgrading to the patched versions of React and Next.js should be the first step for any affected application. Given a validated PoC against default configurations, patching must be prioritized immediately.

Beyond upgrading, the most effective mitigation available today is to deploy a Web Application Firewall (WAF) rule in front of applications that expose React Server Components endpoints.

Cloud providers have already released managed WAF rulesets for React2Shell. Examples of official provider guidance include:

• AWS: https://aws.amazon.com/security/security-bulletins/rss/aws-2025-030/
• Cloudflare: https://blog.cloudflare.com/waf-rules-react-vulnerability/
• Google Cloud: https://cloud.google.com/blog/products/identity-security/responding-to-cve-2025-55182

If your environment requires a custom rule, the following AWS WAF example demonstrates the core detection logic used to match suspicious RSC payloads:

{
  "Name": "ReactJSRCE_CUSTOM",
  "Priority": 99,
  "Statement": {
    "AndStatement": {
      "Statements": [
        {
          "RegexMatchStatement": {
            "RegexString": "POST",
            "FieldToMatch": {
              "Method": {}
            },
            "TextTransformations": [
              {
                "Priority": 0,
                "Type": "NONE"
              }
            ]
          }
        },
        {
          "RegexMatchStatement": {
            "RegexString": "(?i)(?:next-action|rsc-action-id)",
            "FieldToMatch": {
              "Headers": {
                "MatchPattern": {
                  "All": {}
                },
                "MatchScope": "KEY",
                "OversizeHandling": "CONTINUE"
              }
            },
            "TextTransformations": [
              {
                "Priority": 0,
                "Type": "NONE"
              }
            ]
          }
        },
        {
          "RegexMatchStatement": {
            "RegexString": "(?i)\"status\"\\s*:\\s*\"resolved_model\"",
            "FieldToMatch": {
              "Body": {
                "OversizeHandling": "CONTINUE"
              }
            },
            "TextTransformations": [
              {
                "Priority": 0,
                "Type": "URL_DECODE_UNI"
              },
              {
                "Priority": 1,
                "Type": "JS_DECODE"
              },
              {
                "Priority": 2,
                "Type": "UTF8_TO_UNICODE"
              }
            ]
          }
        },
        {
          "RegexMatchStatement": {
            "RegexString": "\\$\\@",
            "FieldToMatch": {
              "Body": {
                "OversizeHandling": "CONTINUE"
              }
            },
            "TextTransformations": [
              {
                "Priority": 0,
                "Type": "URL_DECODE_UNI"
              },
              {
                "Priority": 1,
                "Type": "JS_DECODE"
              },
              {
                "Priority": 2,
                "Type": "UTF8_TO_UNICODE"
              }
            ]
          }
        }
      ]
    }
  },
  "Action": {
    "Block": {}
  },
  "RuleLabels": [
    {
      "Name": "ReactJSRCE_Custom"
    }
  ],
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "ReactJS_Custom"
  }
}

Teams can also quickly confirm whether the WAF rule is active using a simple POST request:

curl -i -X POST \
    -A "CVE-2025-55182-WAF-Rule/1.0" \
    -H "next-action: some-action" \
    -d '"status"\:\"resolved_model"\$\@' \
    "<YourHost>"

Below is an example of how a blocked request appears in AWS WAF logs:

Understanding Framework Risk and How to Verify Your Exposure

React2Shell highlights an important pattern in modern frameworks. As frameworks adopt richer server-side functionality, they also expand the attack surface in ways most teams do not immediately see. The vulnerability disclosure process for this issue was executed clearly by the React and Next.js teams, with a well-defined upgrade path and effective mitigations available at various cloud providers.

Teams should still verify where vulnerable packages appear in their environment. Package-level visibility helps confirm whether a project includes the React Server Components dependencies where this issue originates. Platforms like Averlon can surface this quickly:

If you use GitHub, Dependabot will alert you when your application includes the affected packages or dependent versions:

Clear remediation steps, available WAF rules, and a straightforward upgrade path make this a well-managed incident. The remaining task for teams is to ensure they understand where React Server Components appear in their applications and take the appropriate patching and mitigation steps.

How Averlon Can Help

Averlon helps teams working through React2Shell by identifying where the vulnerable React Server Components packages are used across their applications, including cases where frameworks introduce them automatically. This gives teams a clear view of which projects rely on the affected packages and need to be upgraded.

Averlon also surfaces which applications are externally exposed so they can be prioritized for patching, if needed. Publicly reachable React or Next.js services should be addressed first, while internal-only systems may follow on a different schedule.

Once affected packages are identified, Averlon can generate pull requests that upgrade React or Next.js to patched versions. Engineers remain fully in control of the review and deployment process, while the repetitive work of finding impacted projects and preparing upgrades is streamlined.

What to Monitor as React2Shell (CVE-2025-55182) Research Evolves

CVE-2025-55182 remains an active area of research as security teams and framework maintainers continue to evaluate how the vulnerable React Server Components code paths behave in real deployments. With a validated public exploit now available for default configurations, the baseline threat has increased. Teams should assume that unpatched applications are at risk, and prioritize remediation and exposure audits accordingly.

Teams can stay ahead by upgrading to the patched versions of React and Next.js, reviewing whether their applications expose React Server Component endpoints, and applying the available WAF mitigations. We will continue to track developments in React2Shell research and update this analysis as new exploit techniques or framework behaviors emerge.