The npm ecosystem can’t catch its breath. React4Shell (React2Shell) is the latest flashpoint: two CVSS 10.0 remote code execution vulnerabilities tied to React Server Components (RSC) and the Flight protocol. CVE-2025-55182 (React) is the core bug, enabling unauthenticated RCE through Flight payload handling. CVE-2025-66478 (Next.js) tracks the same worst-case outcome through Next.js’ RSC integration.
What makes this one ugly is the speed of operationalization. Dec 3, 2025 brought disclosure at maximum severity. Early on, exploitation wasn’t broadly visible. That window closed fast. By Dec 4, researchers confirmed reliable unauthenticated RCE, PoCs began circulating across dozens of GitHub repositories, and late-evening telemetry showed a sharp rise in probing and exploit attempts. AWS threat intelligence reporting also described rapid exploitation attempts by China-nexus groups soon after disclosure, the kind of “hours-not-weeks” shift defenders associate with Log4J-style internet-scale sweeps.
If you’re running a modern React SSR or Next.js App Router with anything touching RSC, streaming, or Flight, treat this as an incident: patch immediately, verify what’s deployed, then audit exposure and logs. The most likely mass-exploitation path is the default, reachable Next.js applications that expose the RSC/Server Action surface area without teams realizing it.
TL;DR for engineering teams
- This is unauthenticated RCE through React Server Components (RSC) Flight payload decoding. If the endpoint is reachable, credentials are optional.
- PoCs are circulating (we’re seeing multiple repos referencing React4Shell / React2Shell / Freight Night patterns). One example repo: https://github.com/liyander/React2shell-poc
- Fastly reports active probing and recommends enabling a Virtual Patch for the dual CVEs on Next-Gen WAF.
- Patch React RSC server-dom packages and Next.js to fixed releases. Treat “merged” as meaningless until production artifacts are updated.
What changed (React4Shell update)
This vulnerability is now being discussed and tracked by teams under React4Shell / React2Shell / Freight Night, and coverage in public reporting is already framing it as a practical, internet-scale exploitation story. Currently, the vulnerability is being exploited on a large scale, with attribution to Chinese threat actors for scale.
Update on #React2Shell: We’re aware of a PoC circulating that appears viable for CVE-2025-55182 and CVE-2025-66478 in React and Next.js. Example PoC repo: https://github.com/liyander/React2shell-poc
For Full technical anatomy: https://phoenix.security/react-nextjs-cve-2025-5518/
Timeline of exploitation for RCE in React RSC Flight (CVE-2025-55182) and Next.js (CVE-2025-66478)
Rapid, expected timeline for this remote code execution (RCE) vulnerability in React Server Components (CVE-2025-55182) and Next.js (CVE-2025-66478) shows a rapid progression from initial report to confirmed, active exploitation by threat actors.
The vulnerability saw a flurry (72 poc) of poc on the first day and rapid exploitation on the 4th.
Discovery and Disclosure Timeline
The coordinated disclosure timeline occurred over five days in late November and early December 2025:
| Date | Event | Details |
| Nov 29, 2025 | Vulnerability Reported | The security vulnerability was reported by Lachlan Davidson via the Meta Bug Bounty program. |
| Nov 30, 2025 | Confirmation and Fix Development | Meta security researchers confirmed the issue and began working with the React team on developing a fix. |
| Dec 1, 2025 | Fix Created and Coordination | A fix was created, and coordination began with affected hosting providers (such as AWS and Vercel) and major open-source projects to validate the fix and roll it out, along with implementing temporary mitigations. |
| Dec 3, 2025 | Public Disclosure and Patch Release | The fix was published to npm, and the vulnerability was publicly disclosed as CVE-2025-55182 (React) and CVE-2025-66478 (Next.js). |
| Dec 4 2025 | ◦ Prior to 23:00 GMT on December 4th, there was broad distribution and cloning of PoCs, with approximately 72 different repositories referencing terms like React4Shell / React2Shell / Freight Night. (vulncheck) | |
| Dec 4 2025 | AWS Threat Acrot Confirmation | AWS confirms exploitation linked to Chinese threat actors (AWS Blog) |
| Dec 4 2025 | GCP Notification | Google Cloud Confirm rules in Cloud Armor (GCP Cloud Blog) |
| Dec 4, 2025 | Vulncheck Confirm Evidence of exploitation | (validation and PoC spread): vulncheck research team confirmed unauthenticated RCE is reliably exploitable, and a PoC achieving unauthenticated RCE became public during the afternoon of Dec 4. (VulnCheck also notes availability of a weaponized exploit to its paying customers.) |
| Dec 4-5, 2025 | Fastly Confirm Rapid Ramp-up in Exploitation | Fastly Confirm exploitation on virtual appliances from 9 pm onward (GMT) – Linkedin post |
Get a Free Posture assessment today
Post-Disclosure Exploitation and Operationalization
The most critical aspect of the timeline is the immediate operationalization by threat actors following public disclosure on December 3, 2025:
- Immediate Exploitation Attempts (Dec 3): Within hours of the public disclosure on December 3, 2025, Amazon threat intelligence teams observed active exploitation attempts by multiple China state-nexus threat groups, including Earth Lamia and Jackpot Panda, consistent with how high-impact RCE bugs are industrialized.
- Confirmed Exploitable (Dec 4): On December 4th, VulnCheck’s research team confirmed that the vulnerability is reliably exploitable for unauthenticated RCE.
- Public PoC Release (Dec 4 – Afternoon): A Proof-of-Concept (PoC) exploit that achieves unauthenticated RCE became public during the afternoon of December 4th.
- Dec 4th Prior to 23:00 GMT on December 4th, there was broad distribution and cloning of PoCs, with approximately 72 different repositories referencing terms like React4Shell / React2Shell / Freight Night.
- Fastly also reported active probing and recommended enabling a Virtual Patch on their Next-Gen WAF.
- Exploitation Spike (Dec 4 – Evening GMT): Telemetry indicated a sharp rise in probing/exploitation attempts in the late evening GMT window, specifically between 21:00 and 23:00 GMT, which aligns with the widespread circulation of PoCs.
The vulnerability was operationalized rapidly because it has the “bad chemistry” pattern of being framework-layer, internet-facing by default, and easy to probe at scale, similar to the Log4J vulnerability. Attackers target Next.js App Router deployments specifically, as they are often internet-reachable and include the vulnerable RSC plumbing out of the box.
What changed after disclosure
- Dec 3, 2025 (public disclosure): CVE-2025-55182 (React) and CVE-2025-66478 (Next.js) disclosed as CVSS 10 unauthenticated RCE in the React RSC Flight protocol / server-dom packages and affected frameworks. Early summaries initially reported no public PoC and no confirmed exploitation at the moment of disclosure.
- Dec 4, 2025 (validation and PoC spread): VulnCheck’s research team confirmed unauthenticated RCE is reliably exploitable, and a PoC achieving unauthenticated RCE became public during the afternoon of Dec 4. (VulnCheck also notes availability of a weaponized exploit to its paying customers.)
- Dec 4, 2025 (PoC repo proliferation): Prior to 23:00 GMT there was limited exploitation volume visible in public chatter, but there was broad PoC cloning and repackaging across dozens of GitHub repos referencing React4Shell / React2Shell / Freight Night terms. (Track this as “PoC distribution” rather than “exploitation.”)
- Dec 4, 2025 (21:00–23:00 GMT spike window): Telemetry shared publicly indicates a sharp rise in probing/exploitation attempts in the late evening GMT window, consistent with exploit operationalization once PoCs began to circulate widely.
- Dec 4, 2025 (state-nexus activity reported): Reporting and threat intel writeups claim multiple China-nexus threat groups moved quickly to attempt exploitation after disclosure, consistent with how high-impact RCE bugs get industrialized within hours to days.
Why Next.js is the primary attack surface
- Default Next.js App Router deployments are frequently internet-reachable and include RSC plumbing out of the box, which makes them a high-probability entry point for opportunistic scanning and exploitation.
Why defenders should care (this feels like Log4J)
This has the same “bad chemistry” pattern defenders learned the hard way with Log4J:
- It’s framework-layer, not app-layer.
- It’s internet-facing by default in many deployments.
- It’s easy to probe at scale, so attackers can run this like a sweep, not a bespoke operation.
Technical anatomy (high level, defender-safe)
React Server Components rely on the Flight protocol to move serialized payloads between client and server. The weakness sits in server-side decoding and deserialization of attacker-controlled payloads, enabling execution on the server when a vulnerable RSC / Server Action path is reachable.
For Full technical anatomy: https://phoenix.security/react-nextjs-cve-2025-5518/
Core behaviors after successful exploitation
Once an attacker gets code execution, the playbook is boring and effective:
- Secret harvesting: env vars, .env, CI tokens, signing keys
- Cloud pivot: metadata endpoints, secret managers, role tokens
- Persistence: modify server artifacts, drop backdoors where writable
- Lateral movement: internal services, databases, queues
This is why the blast radius can jump from “one web app” to “cloud control plane” fast.
Affected versions
React (CVE-2025-55182)
Vulnerable
- react-server-dom-webpack: 19.0.0, 19.1.0, 19.1.1, 19.2.0
- react-server-dom-parcel: 19.0.0, 19.1.0, 19.1.1, 19.2.0
- react-server-dom-turbopack: 19.0.0, 19.1.0, 19.1.1, 19.2.0
Fixed
- 19.0.1, 19.1.2, 19.2.1
Next.js (CVE-2025-66478)
Impacted lines:
- 14.3.0 pre-release line: 14.3.0-(pre-release).77 and later (App Router)
- All 15.x
- All 16.x
Patched releases (by line):
- 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7
RedwoodJS (rwsdk)
- Ensure rwsdk >= 1.0.0-alpha.0, and update React/React DOM plus the relevant react-server-dom-* package(s) to fixed versions.
Active exploitation and probing signals
Public reporting already frames this as an actively exploited, high-reliability RCE class issue.
Fastly’s public communications also indicate attackers actively probing and recommends enabling the virtual patch where applicable on their Next-Gen WAF.
How to tell if you’re exposed
- Search lockfiles for react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack and match versions above.
- Map runtime exposure: which services actually expose RSC / Server Action endpoints to the internet.
- Check deployed artifacts: container images, serverless bundles, AMIs. Source repo correctness is not enough.
Fix (what “done” looks like)
- Upgrade React RSC server-dom packages to 19.0.1 / 19.1.2 / 19.2.1.
- Upgrade Next.js to a patched release in your line (15.0.5 … 16.0.7).
- Redeploy and confirm production versions from the running environment.
What a bad version look like:
| Other examples of vulnerable versions: https://github.com/Security-Phoenix-demo/react2shell-scanner-rce-react-next-CVE-2025-55182-CVE-2025-66478/tree/main/test_samples This version is purposely vulnerable; we pinned the versionreact-server-dom-webpack 19.1.0 → affected (vulnerable versions include 19.1.0). react 19.1.0 and react-dom 19.1.0 line up with that vulnerable RSC server-dom package. What to upgrade to (fix)Upgrade react-server-dom-webpack to a fixed version in the same line:19.1.2 (recommended), or move to 19.2.1 if you’re ready for that line. Do the same for React + React DOM so peers stay consistent.Minimal commandnpm install react@19.1.2 react-dom@19.1.2 react-server-dom-webpack@19.1.2Quick verificationAfter install, confirm the resolved versions:npm ls react react-dom react-server-dom-webpack |
Mitigations while patching (WAF and containment)
Fastly Next-Gen WAF
Fastly documents Virtual patches for CVEs and advises enabling relevant coverage to block or log exploit-matching traffic.
AWS WAF
If you’re on AWS WAF, apply the managed-rule coverage and custom rule approach you already drafted (observe first, then block). Keep it as a stopgap, not “the fix”.
Containment that actually helps
- Rate-limit and bot-gate suspicious POST patterns to RSC/Action endpoints.
- Reduce outbound egress from web tiers where possible.
- Rotate secrets if you detect suspicious requests that reached application decoding paths.
PoC tracking links (for awareness)
- Phoenix Security advisory page: https://phoenix.security/react-nextjs-cve-2025-5518/
- Example PoC repo: https://github.com/liyander/React2shell-poc
- Phoenix Security GitHub repo: https://github.com/Security-Phoenix-demo/freight-night-rce-react-next-CVE-2025-55182-CVE-2025-66478
- Shai Hulud overview (context on ecosystem-scale abuse): https://phoenix.security/shai-hulud-second-coming-npms-biggest-supply-chain-breach/
Campaign to identify if your libraries are affected by the React2Shell Phoenix security
Leverage the Phoenix Security SCA Scanner to identify the vulnerability blast radius
Scan with the Git automatic scanner or pull the repo individually (finding can be synced to Phoenix using –enable-phoenix and modifying the config: https://github.com/Security-Phoenix-demo/react2shell-scanner-rce-react-next-CVE-2025-55182-CVE-2025-66478
Leverage Phoenix Security Filters and the campaign method to update/ retrieve the new vulnerabilities, or import those two files
Check the libraries not affected in SBOM screen to detect React2Shell (search the following libraries)
- React-server-dom-webpack
- webpack
- React-server-dom-parcel
- parcel
- React-server-dom-turbopack
- Turbopack
- react-router
- Next.js
- plugin-rsc
- Waku
- Rwsdk
- rsc
Check Vulnerability Screen in Phoenix Security
Determine If You’re Affected
Use this as a fast triage checklist for application security and vulnerability management teams.
- Do you run React on a server with RSC enabled?
- If you do server-rendered React and RSC is in play, assume yes.
- If you do server-rendered React and RSC is in play, assume yes.
- Search your lockfiles for the vulnerable packages and versions
- react-server-dom-webpack
- react-server-dom-parcel
- react-server-dom-turbopack
- react-server-dom-webpack
- Confirm whether your framework bundles the server implementation
- Next.js is the obvious one, but RSC-capable stacks and plugins can carry these dependencies indirectly.
- Next.js is the obvious one, but RSC-capable stacks and plugins can carry these dependencies indirectly.
- Map exposure
- Identify which services expose RSC-related endpoints externally.
- Prioritize public-facing workloads, then internal apps reachable from untrusted networks.
- Identify which services expose RSC-related endpoints externally.
- ASPM angle
- Correlate the vulnerable component to runtime deployments, owners, and routes. If you cannot answer “where is this running,” you are already behind.
- Correlate the vulnerable component to runtime deployments, owners, and routes. If you cannot answer “where is this running,” you are already behind.
WAF Rule to protect against (CVE-2025-55182) and Next.js (CVE-2025-66478)
Custom rule option (interim protection)
As an interim protection measure, customers can deploy a custom AWS WAF rule to help detect and prevent exploitation attempts where applicable. The rule below is currently set to BLOCK. Test first in your environment (start in COUNT if you need to validate impact) to avoid breaking legitimate traffic patterns.
AWS is actively monitoring for updates on this issue. If you need additional details or assistance, open an AWS Support case.
Adding a custom AWS WAF rule
Use the following JSON as a starting point:
1) “Observe first” rule (COUNT + label)
Use this to measure real traffic impact and capture samples before you start blocking.
{
“Name”: “ReactJSRCE_OBSERVE”,
“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”: { “Count”: {} },
“RuleLabels”: [{ “Name”: “ReactJSRCE_Observe” }],
“VisibilityConfig”: {
“SampledRequestsEnabled”: true,
“CloudWatchMetricsEnabled”: true,
“MetricName”: “ReactJS_Observe”
}
}
- Let it run long enough to cover peak traffic.
- Review sampled requests and the metric ReactJS_Observe.
- If you see legit traffic matching, you either tune the rule (scope it to specific paths/hosts) or accept the tradeoff before blocking.
Break-glass (strict BLOCK, optimized for speed)
2) “Stop the bleeding” rule (BLOCK + label)
This is your rapid containment version.
{
“Name”: “ReactJSRCE_BREAKGLASS_BLOCK”,
“Priority”: 10,
“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” }]
}
},
{
“OrStatement”: {
“Statements”: [
{
“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_Breakglass” }],
“VisibilityConfig”: {
“SampledRequestsEnabled”: true,
“CloudWatchMetricsEnabled”: true,
“MetricName”: “ReactJS_Breakglass”
}
}
Deployment guidance
- If you have multiple apps behind one WAF, attach by host/path if possible (ALB host-based routing patterns, CloudFront behaviors, or separate Web ACLs). A global blunt instrument is where false positives come from.
- Keep AWSManagedRulesKnownBadInputsRuleSet (v1.24) enabled. Your custom rule is additive.
- If you see noise from legitimate RSC traffic, the cleanest tuning lever is path scoping (match only the RSC/Server Action endpoints your apps actually use).
Installation base, widespread impact, and criticality
React and Next.js sit in the center of modern web delivery. React Server Components moved quickly from “new architecture” to “default path” in many teams adopting App Router and server-first patterns. That drives two uncomfortable realities:
- Wide propagation through dependency graphs: even teams that never typed the vulnerable package name can inherit it through frameworks and plugins.
- Internet exposure is common by design: these are web-facing runtimes. Attackers do not need internal access or credentials.
- Criticality is absolute: unauthenticated RCE at the framework layer is a top-tier incident class. The exploit lands before your app logic gets a vote.
If your org runs multiple Next.js services, assume more than one is exposed. If you run a platform team that “standardizes” frontend scaffolds, assume you standardized the vulnerability too.
Final guidance for DevSecOps, ASPM, and AppSec teams
- Patch fast, then verify deployment reality. “Merged the PR” is not remediation. Confirm the patched versions are actually running in production images.
- Prioritize by reachability and exposure. Public endpoints first. Then anything reachable from semi-trusted networks.
- Hunt with intent. Review edge logs for suspicious spikes and malformed requests to RSC-related endpoints around and after patch disclosure.
- Use ASPM to collapse chaos into ownership. One backlog, mapped to teams, tied to runtime, with deduplication and reachability. Otherwise you will be chasing dependency noise while attackers are chaining impact.
If you want, paste your package.json plus lockfile snippet (or just the dependency tree output) and I’ll turn it into a concrete “affected or not” call with the exact upgrade path per app.
=====
How Phoenix Security Can Help
Organizations often face an overwhelming volume of security alerts, including false positives and duplicate vulnerabilities, which can distract from real threats. Traditional tools may overwhelm engineers with lengthy, misaligned lists that fail to reflect business objectives or the risk tolerance of product owners.
Phoenix Security offers a transformative solution through its Actionable Application Security Posture Management (ASPM), powered by AI-based Contextual Quantitative analysis and an innovative Threat Centric approach. This innovative approach correlates runtime data with code analysis and leverages the threats that are more likely to lead to zero day attacks and ransomware to deliver a single, prioritized list of vulnerabilities. This list is tailored to the specific needs of engineering teams and aligns with executive goals, reducing noise and focusing efforts on the most critical issues. Why do people talk about Phoenix
• Automated Triage: Phoenix streamlines the triage process using a customizable 4D risk formula, ensuring critical vulnerabilities are addressed promptly by the right teams.
• Contextual Deduplication: Utilizing canary token-based traceability, Phoenix accurately deduplicates and tracks vulnerabilities within application code and deployment environments, allowing teams to concentrate on genuine threats.
• Actionable Threat Intelligence: Phoenix provides real-time insights into vulnerability’ exploitability, combining runtime threat intelligence with application security data for precise risk mitigation.
By leveraging Phoenix Security, you not only unravel the potential threats but also take a significant stride in vulnerability management, ensuring your application security remains up to date and focuses on the key vulnerabilities.
