The npm ecosystem can’t seem to catch its breath: two freshly disclosed, maximum-severity (CVSS 10.0) remote code execution bugs are putting React Server Components (RSC) deployments back under the microscope—CVE-2025-55182 (React), a critical issue in the Flight protocol that can enable unauthenticated RCE, and CVE-2025-66478 (Next.js), a corresponding Next.js-tracked vulnerability with the same worst-case outcome. If you’re running modern React/Next.js stacks—especially anything touching RSC, streaming, or Flight payload handling—this is the kind of “patch-now, verify-exposure, then audit” incident, not next sprint’s housekeeping.
TL;DR for the engineering team
- This is unauthenticated RCE against React Server Components (RSC) payload handling in the “Flight” protocol. That’s the kind of bug that turns “web app” into “server shell” with one request.
- Default setups are in scope. If you run Next.js with App Router and production builds, you may be exploitable even if you never wrote a “server function” on purpose.
- Fix requires upgrading React RSC server DOM packages and Next.js to patched releases. Do not rely on hosting mitigations as your primary control.
- Treat this as an incident, not a routine upgrade. Look for suspicious requests to RSC-related endpoints, rotate secrets if you suspect exposure, and tighten request filtering until you patch.
- 39% of the cloud instances could be affected, according to AWS and Wiz research
- Deck for an Internal presentation (always adapt and check this has been AI generated, LLM make mistakes)
Technical anatomy
React Server Components rely on the Flight protocol to move serialized component trees and action calls between client and server. The weakness here sits in how the server decodes and deserializes attacker-controlled payloads delivered to RSC / Server Function endpoints.
At a high level:
- The attacker sends a crafted HTTP request that targets a server endpoint involved in RSC/Server Function handling.
- The server uses React’s decoding logic to deserialize the Flight payload.
- Insecure deserialization lets the attacker influence server-side execution, escalating into remote code execution.
Non-authenticated RCE are particularly dangerous; nevertheless, there are WAF rules that could mitigate this vulnerability (see section below)
Core behaviours
Here’s what defenders should assume an attacker will do after landing RCE:
- Environment discovery: enumerate runtime, file system layout, environment variables, cloud metadata endpoints.
- Secret hunting: pull .env, deployment secrets, CI tokens, service credentials, signing keys.
- Persistence: drop webshell-like artifacts, modify server-side code, implant scheduled tasks where possible.
- Lateral movement: pivot into internal services, databases, message queues, and cloud APIs.
- Supply chain follow-on: if build or deploy credentials are present, attackers go upstream to CI/CD.
If your DevSecOps pipeline treats the web tier as “just a frontend,” this vulnerability will punish that assumption.
Affected Versions
React (CVE-2025-55182)
Vulnerable package versions (as stated by the React team):
- 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 versions:
- 19.0.1, 19.1.2, 19.2.1
- Patched in React 19.2.1
- Fix: https://github.com/facebook/react/commit/7dc903cd29dac55efb4424853fd0442fef3a8700
- Announcement: https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components
Practical read: if you see any of those RSC server DOM packages in the vulnerable versions anywhere in your dependency graph, treat the service as vulnerable until upgraded.
Next.js (CVE-2025-66478)
The provided material flags Next.js as broadly impacted through its RSC integration.
In-scope Next.js ranges called out:
- 14.3.0 pre-release line: 14.3.0-(pre-release).77 and later (App Router)
- All 15.x
- All 16.x
Patched Next.js releases (by release line):
- 15.0.5 (for 15.0.x)
- 15.1.9 (for 15.1.x)
- 15.2.6 (for 15.2.x)
- 15.3.6 (for 15.3.x)
- 15.4.8 (for 15.4.x)
- 15.5.7 (for 15.5.x)
- 16.0.7 (for 16.0.x)
Discovery and Disclosure Timeline
- Nov 29, 2025: Vulnerability reported by Lachlan Davidson via Meta Bug Bounty.
- Nov 30, 2025: Meta security researchers confirmed and worked with the React team on a fix.
- Dec 1, 2025: Fix created; validation with hosting providers and major projects; mitigations coordinated.
- Dec 3, 2025: Fix published to npm and publicly disclosed as CVE-2025-55182.
Get in touch for a maturity assessment
Campaign to identify if your libraries are affected by the 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
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.
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.
Distribution of the packages
RSC “packet” distribution (weekly downloads, download-weighted)
Weekly downloads:
- react-server-dom-webpack: 672,086
- react-server-dom-turbopack: 43,421
- react-server-dom-parcel: 7,170
Total = 672,086 + 43,421 + 7,170 = 722,677
Shares:
- webpack: 672,086 / 722,677 = 92.99%
- turbopack: 43,421 / 722,677 = 6.01%
- parcel: 7,170 / 722,677 = 0.99%
Bundlers distribution (weekly downloads, download-weighted) — unchanged, now complete
Weekly downloads:
- react-router: 19,999,549
- next: 16,697,083
- @vitejs/plugin-rsc: 59,869
- waku: 6,434
- rwsdk: 3,372
- @parcel/rsc: 3,089
Total = 36,769,396
Shares:
- react-router: 54.39%
- Next.js: 45.41%
- @vitejs/plugin-rsc: 0.163%
- waku: 0.0175%
- rwsdk: 0.0092%
- @parcel/rsc: 0.0084%
Temporary Protections
These are stopgaps. They buy time. They do not close the book.
- Block or strictly filter RSC/Server Function endpoints at the edge
- If you can scope the path surface area, do it. If you cannot, that’s a signal your routing hygiene is weak.
- If you can scope the path surface area, do it. If you cannot, that’s a signal your routing hygiene is weak.
- WAF rules for payload anomalies
- Look for unusual request shapes and oversized payloads targeting RSC endpoints. Focus on preventing the request from reaching the application runtime.
- Look for unusual request shapes and oversized payloads targeting RSC endpoints. Focus on preventing the request from reaching the application runtime.
- Rate limiting and bot gating
- RCE probing often ramps quickly. Reduce attacker iteration speed.
- RCE probing often ramps quickly. Reduce attacker iteration speed.
- Reduce blast radius
- Lock down outbound egress where feasible.
- Enforce least privilege on service credentials.
- Ensure the runtime identity cannot modify infrastructure or fetch secrets broadly.
- Lock down outbound egress where feasible.
If you run workloads behind AWS WAF, you’ve got a practical defense-in-depth option while you patch.
Managed rule coverage (interim safety net)
- The default version (1.24) of AWSManagedRulesKnownBadInputsRuleSet now includes the updated rule for this issue.
- Treat this as a seatbelt, not the airbag. You still patch React/Next.js.
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).
How threat actors could use this vulnerability
If you are running a vulnerable stack, the attacker’s path is brutally simple:
- Recon
- Identify a Next.js/React RSC target.
- Fingerprint endpoints and framework behavior (headers, routes, response patterns).
- Identify a Next.js/React RSC target.
- Single-request compromise
- Send a crafted HTTP request that triggers the vulnerable deserialization in Flight payload decoding.
- Achieve code execution inside the server runtime.
- Send a crafted HTTP request that triggers the vulnerable deserialization in Flight payload decoding.
- Instant monetization
- Pull environment variables, config files, cloud tokens.
- Dump database credentials.
- Exfiltrate secrets that unlock broader systems: CI/CD, object storage, key vaults.
- Pull environment variables, config files, cloud tokens.
- Persistence and expansion
- Implant backdoors where possible.
- Pivot into internal services, then into control planes if credentials allow.
- Implant backdoors where possible.
- Damage choices
- Ransom, data theft, cryptomining, or surgical supply chain compromise. RCE is a universal adapter.
- Ransom, data theft, cryptomining, or surgical supply chain compromise. RCE is a universal adapter.
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.
