React2Shell (CVE-2025-55182)

WAF bypass mitigations and detection rules for the React Server Components RCE vulnerability. This page consolidates vendor advisories and provides custom rules for known bypasses, updated as new evasion techniques are discovered.

Am I Vulnerable?

Select your package and enter the version to check if you're affected by CVE-2025-55182 / CVE-2025-66478

Run this command to fix:

Package	Vulnerable Version	Patched Release
Next.js
	13.3.x, 13.4.x, 13.5.x	14.2.35
	14.x	14.2.35
	15.0.x	15.0.7
	15.1.x	15.1.11
	15.2.x	15.2.8
	15.3.x	15.3.8
	15.4.x	15.4.10
	15.5.x	15.5.9
	16.0.x	16.0.10
	14 canaries after 14.3.0-canary.76	Downgrade to 14.2.35
	15 canaries before 15.6.0-canary.60	15.6.0-canary.60
	16 canaries before 16.1.0-canary.19	16.1.0-canary.19
React
	19.0.0	19.0.1
	19.1.0, 19.1.1	19.1.2
	19.2.0	19.2.1

1 What's Going On

React2Shell (CVE-2025-55182) is a critical RCE vulnerability (CVSS 10.0) in React Server Components, disclosed on December 3rd. It allows unauthenticated attackers to execute arbitrary code on your server. Security researcher Lachlan Davidson reported it to Meta on November 29th.

📢 December 11th Update: Two additional vulnerabilities were disclosed: DoS (CVE-2025-55184, High) and source code exposure (CVE-2025-55183, Medium). These are not as severe as React2Shell (no RCE), but if you patched for React2Shell, you'll need to update again to address these new issues.

Attackers continue to find ways around WAF protections. This page tracks the ongoing situation and provides updated mitigation rules as new bypasses are discovered.

Nov 29

Reported to Meta

Dec 3

Public disclosure
Patches + WAF rules

Active exploitation

Dec 5

Public POC

Dec 6

Cloudflare bypass
Disclosed by Miggo

Dec 8

AWS WAF bypass
Disclosed by Miggo

Dec 10

Akamai bypass
Disclosed by Miggo

Dec 11

New CVEs disclosed
DoS + Source leak

Now

Monitoring

⚡

Why WAFs Fail

WAFs have inherent limits that attackers quickly find and abuse. They only inspect the first few KB of requests and don't decode all encodings. This page tracks discovered bypasses and provides updated rules to address them.

2 How to Fix Your WAF

Most exploitation attempts we're observing abuse WAF inspection limits and encoding tricks. Attackers prepend junk data to push malicious payloads past the first few KB that WAFs inspect, or use character encodings (like custom charsets) that WAFs don't decode but Next.js does.

Our rules block oversized requests with the Next-Action header, as well as requests containing charset declarations that could bypass WAF inspection. As new bypasses are discovered by us or the community, we update the rules and notify vendors.

⚠️ The real fix is patching

Update React to 19.0.3+, 19.1.4+, or 19.2.3+ and Next.js to the latest patched versions in your release line. If you already patched for React2Shell, update again for the Dec 11 CVEs.

See official advisories for version tables: React (Dec 3) · React (Dec 11) · Next.js

WAF rules provide defense-in-depth while you patch, but are not a substitute for patching. Consider runtime mitigations as an additional layer.

3 Deploy Rules

All major WAF vendors have released rules for this vulnerability. We provide additional Miggo rules to address bypasses as they become known to us. Rules are versioned and we continuously monitor for new evasion techniques, so bookmark this page and check back for updates.

📋 Before deploying Miggo rules: Keep your vendor's managed rules enabled as your baseline protection. Miggo rules are deployed in addition to address known bypasses. These rules are intentionally strict and may block legitimate Server Actions (e.g., file uploads, large form submissions). Test thoroughly in staging before production. For large uploads, consider API routes or signed URL flows.

Cloudflare Miggo rule v1.2 Managed + Custom

1 Enable the Cloudflare Managed Ruleset. Go to Security → WAF → Managed Rules. Enable the Cloudflare Managed Ruleset with action set to Block (not just Log), as Cloudflare has deployed rules specifically for this vulnerability.

2 Add a custom bypass protection rule. The managed rules can be bypassed by prepending junk data. Pick the rule matching your plan:

Pro / Business (block 8KB+, encoding tricks, or pattern match)

              
              (http.request.method eq "POST") and 
(any(http.request.headers.names[*] matches "(?i)(?:next-action|rsc-action-id)")) and
(
  (http.request.body.size ge 8192) or
  (http.request.body.raw matches "(?i)charset=") or
  (http.request.body.raw contains "\\u00") or
  (
    (http.request.body.raw contains "_formData") and
    (http.request.body.raw contains "_response") and
    (http.request.body.raw contains "resolved_model") and
    (http.request.body.raw contains ":constructor")
  )
)
            

Why these rules? We block custom charsets because Cloudflare doesn't inspect certain encodings that Next.js supports. Cloudflare initially raised WAF inspection limits to 1MB across all plans, but reverted to original sizes (Free: 1MB, Pro/Business: 8KB, Enterprise: 128KB). We recommend paid plan customers contact Cloudflare Support to raise the inspection limit back to 1MB for better protection against bypass attempts.

Enterprise (block 128KB+, encoding tricks, or pattern match)

              
              (http.request.method eq "POST") and 
(any(http.request.headers.names[*] matches "(?i)(?:next-action|rsc-action-id)")) and
(
  (http.request.body.size ge 131072) or
  (http.request.body.raw matches "(?i)charset=") or
  (http.request.body.raw contains "\\u00") or
  (
    (http.request.body.raw contains "_formData") and
    (http.request.body.raw contains "_response") and
    (http.request.body.raw contains "resolved_model") and
    (http.request.body.raw contains ":constructor")
  )
)
            

3 Deploy: Security → WAF → Custom Rules → Create Rule → Action: Block

AWS WAF Miggo rule v1.2 Managed + Custom

1 Update managed rules: Ensure AWSManagedRulesKnownBadInputsRuleSet is updated to v1.24+.

2 Deploy custom rule with OversizeHandling: In addition to the AWS managed rule, add this custom rule with "OversizeHandling": "MATCH" to catch known bypasses:

            
            {
    "Action": {
        "Block": {}
    },
    "Name": "react2shell",
    "Priority": 26,
  "Statement": {
    "AndStatement": {
      "Statements": [
        {
                    "RegexMatchStatement": {
                        "FieldToMatch": {
                            "Method": {}
                        },
                        "RegexString": "POST",
                        "TextTransformations": [
                            {
                                "Priority": 0,
                                "Type": "NONE"
                            }
                        ]
          }
        },
        {
                    "OrStatement": {
                        "Statements": [
                            {
                                "RegexMatchStatement": {
                                    "FieldToMatch": {
                                        "Body": {
                                            "OversizeHandling": "MATCH"
                                        }
                                    },
                                    "RegexString": "(?i)charset=",
                                    "TextTransformations": [
                                        {
                                            "Priority": 0,
                                            "Type": "NONE"
        }
      ]
    }
  },
                            {
                                "RegexMatchStatement": {
                                    "FieldToMatch": {
                                        "Body": {
                                            "OversizeHandling": "MATCH"
                                        }
                                    },
                                    "RegexString": "(?i)resolved_model[\"']|:constructor[\"']|_response[\"']\\s*:|_formData[\"']\\s*:",
                                    "TextTransformations": [
                                        {
                                            "Priority": 0,
                                            "Type": "URL_DECODE_UNI"
                                        },
                                        {
                                            "Priority": 1,
                                            "Type": "JS_DECODE"
                                        },
                                        {
                                            "Priority": 2,
                                            "Type": "UTF8_TO_UNICODE"
                                        }
                                    ]
                                }
                            }
                        ]
                    }
                },
                {
                    "RegexMatchStatement": {
                        "FieldToMatch": {
                            "Headers": {
                                "MatchPattern": {
                                    "All": {}
                                },
                                "MatchScope": "KEY",
                                "OversizeHandling": "MATCH"
                            }
                        },
                        "RegexString": "(?i)(?:next-action|rsc-action-id)",
                        "TextTransformations": [
                            {
                                "Priority": 0,
                                "Type": "NONE"
                            }
                        ]
                    }
                }
            ]
        }
    },
  "VisibilityConfig": {
    "CloudWatchMetricsEnabled": true,
        "MetricName": "react2shell",
        "SampledRequestsEnabled": true
  }
}
          

Note: This rule uses OversizeHandling: MATCH to block requests exceeding inspection limits.

Akamai Miggo rule v1.1 Managed + Custom

Akamai has deployed an Adaptive Security Engine Rapid Rule for App & API Protector customers.
See the Akamai Security Research Blog for full details.

1 Enable managed rule: Akamai App & API Protector customers are protected by Rapid Rule 3000976.

2 Deploy Miggo custom rule (recommended): For additional protection, block requests with RSC headers that exceed 16KB or match exploit patterns.

            
            {
  "name": "react2shell",
  "description": "Block React Server Components exploitation attempts",
  "conditions": {
    "all": [
      {
        "type": "requestMethodMatch",
        "positiveMatch": true,
        "values": ["POST"]
      },
      {
        "type": "requestHeaderMatch",
        "positiveMatch": true,
        "headerName": "*",
        "matchOperator": "MATCHES_REGEX",
        "matchValue": "(?i)(?:next-action|rsc-action-id)",
        "matchCaseSensitive": false
      },
      {
        "any": [
          {
            "type": "contentLengthMatch",
            "positiveMatch": true,
            "matchOperator": "GREATER_THAN",
            "matchValue": 16384
          },
          {
            "type": "requestBodyMatch",
            "positiveMatch": true,
            "matchOperator": "MATCHES_REGEX",
            "matchValue": "(?i)content-type\\s*:[^\\r\\n]*charset\\s*=",
            "matchCaseSensitive": false
          },
          {
            "type": "requestBodyMatch",
            "positiveMatch": true,
            "matchOperator": "CONTAINS",
            "matchValue": "\\u00",
            "matchCaseSensitive": false
          },
          {
            "all": [
              {
                "type": "requestBodyMatch",
                "positiveMatch": true,
                "matchOperator": "MATCHES_REGEX",
                "matchValue": "(?i)resolved_model\"",
                "matchCaseSensitive": false
              },
              {
                "type": "requestBodyMatch",
                "positiveMatch": true,
                "matchOperator": "MATCHES_REGEX",
                "matchValue": "(?i):constructor",
                "matchCaseSensitive": false
              },
              {
                "type": "requestBodyMatch",
                "positiveMatch": true,
                "matchOperator": "MATCHES_REGEX",
                "matchValue": "(?i)_response\"\\s*:",
                "matchCaseSensitive": false
              },
              {
                "type": "requestBodyMatch",
                "positiveMatch": true,
                "matchOperator": "MATCHES_REGEX",
                "matchValue": "(?i)_formData\"\\s*:",
                "matchCaseSensitive": false
              }
            ]
          }
        ]
      }
    ]
  },
  "action": "DENY"
}
          

Note: Akamai's inspection limit means bypasses above 16KB are possible. This rule blocks oversized requests, encoding tricks (charset, Unicode escapes), and pattern-matches exploit signatures for requests under the limit.

Azure WAF Vendor Advisory

Microsoft has released custom WAF rules for Azure Application Gateway, Application Gateway for Containers, and Azure Front Door.
See the Azure Network Security Blog for full details.

1 Upgrade ruleset (recommended): Upgrade to DRS 2.1 (preferred) or CRS 3.2 for the latest WAF engine.

2 Deploy custom rules: Add the CVE-specific custom rules from the advisory. Example for Application Gateway:

            
            {
  "name": "cve202555182",
  "priority": 1,
  "ruleType": "MatchRule",
  "action": "Block",
  "matchConditions": [
    {
      "matchVariables": [{ "variableName": "PostArgs" }],
      "operator": "Contains",
      "matchValues": ["constructor", "__proto__", "prototype", "_response"],
      "transforms": ["Lowercase", "UrlDecode", "RemoveNulls"]
    },
    {
      "matchVariables": [{ "variableName": "RequestHeaders", "selector": "next-action" }],
      "operator": "Any"
    }
  ]
}
          

Note: Deploy separate rules for next-action and rsc-action-id headers. Azure Front Door requires different rule syntax. DRS 2.1 provides some built-in detection but custom rules are required for full mitigation.

Google Cloud Armor Vendor Advisory

Google Cloud has released a preconfigured Cloud Armor WAF rule for CVE-2025-55182.
See the Google Cloud Security Blog for full details.

1 Add Cloud Armor rule to your backend security policy with the following match condition:

            
            (has(request.headers['next-action']) || has(request.headers['rsc-action-id']) || request.headers['content-type'].contains('multipart/form-data') || request.headers['content-type'].contains('application/x-www-form-urlencoded')) && evaluatePreconfiguredWaf('cve-canary',{'sensitivity': 0, 'opt_in_rule_ids': ['google-mrs-v202512-id000001-rce','google-mrs-v202512-id000002-rce']})
          

2 Set action: deny-403

Note: Firebase Hosting and App Hosting users are already protected. Project Shield users have WAF protections deployed automatically.

F5 Vendor Advisory

F5 has released attack signatures for BIG-IP Advanced WAF/ASM, F5 WAF for NGINX, and NGINX App Protect WAF.
See the F5 Security Advisory for full details.

1 Update attack signatures: Update to ASM-AttackSignatures_20251207_155959.im or later.

2 Enable in blocking mode:

            React Server Components RCE (ID: 200204048)
React Server Components RCE (ID: 200204050)
          

3 Assign signatures to your security policies.

4 Detections

YARA Rules

Community-contributed YARA rules to detect exploitation attempts, webshell indicators, and PoC payloads related to CVE-2025-55182 and CVE-2025-66478 by Florian Roth.

react_pocs_indicators_dec25.yar Neo23x0/signature-base on GitHub

5 Exploitation in the Wild

Reports and analysis of active exploitation attempts observed in the wild.

China-nexus cyber threat groups rapidly exploit React2Shell AWS Security Blog Dec 4 React2Shell Opportunistic Exploitation In The Wild GreyNoise Dec 5 React2Shell: Remote Code Execution in React Server Components Datadog Security Labs Dec 5 PeerBlight Linux Backdoor Exploits React2Shell Huntress Dec 9

FAQ

Common questions about React2Shell.

1 What is React2Shell?

React2Shell is a critical remote code execution (RCE) vulnerability affecting modern applications built with React Server Components (RSC) and frameworks like Next.js.

In simple terms, this vulnerability allows attackers to:

Run code on the server
Access sensitive data
Potentially take control of the application

Because React and Next.js are widely used across the industry, the potential impact is very large. This is why React2Shell is being compared to Log4Shell in scope and urgency.

2 What is the impact of React2Shell, and who is vulnerable?

React2Shell enables unauthenticated remote code execution on servers using:

React Server Components (RSC)
React 19 / React Flight protocol
Frameworks built on RSC (e.g., Next.js, Vercel-hosted or self-hosted)

Impact Summary

No authentication required: exploitation is fully remote
High-value targets include Next.js enterprise deployments
Large-scale exploitation observed worldwide over the last 48–72 hours
Attack surface is massive because RSC adoption is widespread across production applications

3 What is the React2Shell timeline?

Nov 29 Private disclosure: Vulnerability privately reported to Meta by New Zealand based security researcher Lachlan Davidson

Dec 3 Public disclosure: React and Next.js released patched versions; Cloudflare releases emergency WAF generic rule, other vendors follow suite

Dec 5 POC appears: Public proof-of-concept (PoC) code appears, enabling active exploitation

Dec 5+ Mass exploitation begins: Scanning and active attacks escalate globally

Dec 6+ WAF rule bypasses: Widespread bypasses observed soon after as attackers mutate payloads

Dec 11 New CVEs: Two additional vulnerabilities disclosed (DoS + source code exposure). If you patched last week, patch again.

4 What actions do security teams need to take immediately?

1. Patch and Upgrade

Apply vendor patches from Meta, Vercel, and framework maintainers as soon as they become available.

2. Mitigate Through Your WAF While Patching

Even though bypasses exist, WAFs still reduce risk when tuned properly. WAF vendors have published generic rules for this vulnerability. Miggo Security has released customized WAF rules for different vendors, updated for both the vendors' generic limitations and the most recent bypasses (continuously monitored and updated).

3. Enable Runtime Attack Detection

Because bypasses are common, teams need a runtime solution (sensor based) to detect and respond to a breach in real time.

4. Review Logs and Investigate Anomalies

Look for indicators in request metadata: suspicious patterns in POST requests, oversized payloads, and unexpected server-side execution.

5 Does our WAF protect us from React2Shell?

WAFs can and should be used to mitigate exposure while patching, but alone they are not enough. All major WAF vendors released emergency rules, but verified bypasses have been observed across all major providers within 24 hours.

Limitations of Vendor WAF Rules

Request size inspection caps prevent evaluation of oversized payloads
Generic rules fail once attackers mutate payload structure
WAFs lack application-specific context required to reliably detect RSC exploitation
Attackers are already using techniques specifically designed to exceed or evade WAF parsing boundaries

What this means: WAFs cannot replace patching. Generic, out-of-the-box vendor WAF rules need to be customized and continuously updated with latest bypass information. Runtime Attack Detection and Response is required as a second layer of defense.

6 What happened with the Cloudflare outage on December 5?

On December 5, 2025, Cloudflare experienced a ~25 minute global outage affecting approximately 28% of HTTP traffic. According to Cloudflare's post-mortem:

The outage was not caused by a React2Shell breach or attack
The outage was caused by configuration changes made while attempting to increase WAF buffer size from 128KB to 1MB to protect customers against CVE-2025-55182
A secondary change to disable an internal WAF testing tool triggered a bug in their FL1 proxy, causing HTTP 500 errors
Cloudflare engineers identified and reverted the change within 25 minutes