GitHub's advisory database published a reviewed critical update for GHSA-xqc2-xf4c-x3h3 (CVE-2026-126187) on November 10, 2026: unauthenticated remote code execution in React Server Components transport code. The flaw lives in react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack — the packages that serialize and deserialize RSC "flight" payloads between server and client. Maintainers backported fixes to 19.0.9, 19.1.10, 19.2.9, and 19.3.1. If you ship Next.js App Router sites, custom RSC hosts, or agent-generated full-stack apps, patch now and rebuild lockfiles agents may have frozen at vulnerable minors.
TL;DR
| Question | Answer |
|---|---|
| Am I affected? | You use RSC via React 19 react-server-dom-* on versions before the patched releases listed in the advisory |
| Is there a fix? | 19.0.9 / 19.1.10 / 19.2.9 / 19.3.1 per line; see release tags |
| Severity? | Critical 9.5 (CVSS v4), network, low complexity, attack requirements present, no privileges or user interaction |
| Exploited in the wild? | Not stated in the advisory |
| Client-only SPA? | Not affected if you truly have no RSC server path |
| Quick check? | npm ls react-server-dom-webpack (and sibling package names) |
What the advisory says happened
React Server Components move UI work to the server and stream compact binary-ish payloads to the client. The vulnerable code deserializes that stream. CWE-502 — deserialization of untrusted data — is the listed weakness.
Impact wording from GitHub is deliberately narrow:
Crafted payloads targeting frameworks supporting React Server Components can lead to remote code execution. This only affects extremely rare cases where responses transport multiple typed arrays and an attacker-controlled value.
"Extremely rare" does not mean "ignore until next quarter" when the CVSS vector is 9.5 and attack complexity is Low with None required privileges. It means defenders should understand the shape of the bug: an attacker who can influence or reflect RSC responses in the vulnerable configuration may supply a payload that abuses how multiple TypedArray chunks are reassembled during deserialization, turning structured data into executable attacker intent on the server.
The advisory links maintainer fixes across branches (PR discussion threads and companion merges) and points to tagged releases:
Credit on GitHub goes to evolutionstorm as finder.
Affected and patched versions (from GHSA)
| Package | Affected | Patched |
|---|---|---|
react-server-dom-webpack | 19.0.0–19.0.8, 19.1.0–19.1.9, 19.2.0–19.2.8, 19.3.0 | 19.0.9 / 19.1.10 / 19.2.9 / 19.3.1 |
react-server-dom-parcel | same ranges | same patch minors |
react-server-dom-turbopack | same ranges | same patch minors |
Frameworks (Next.js, custom RSC routers, experimental bundlers) typically pin one of these packages. Your job is to read the resolved version in the lockfile after npm install, not assume next semver alone implies safety.
Logical attack chain
This is the defender-facing chain implied by the advisory text; no public proof of concept is bundled in GHSA itself.
- Attacker can send or trigger requests that produce RSC responses from a vulnerable server (public route, SSR action, misconfigured edge, or reflected gadget).
- Response body includes the multiple typed arrays pattern the bug class cares about, with at least one attacker-controlled slot in that pattern.
- Deserialization in
react-server-dom-*mishandles the combination, crossing from data parsing into code execution on the server runtime hosting RSC. - Outcome at CVSS High confidentiality, integrity, and availability on the vulnerable system — full server compromise in the worst case for that process boundary.
Because User interaction is None and Privileges Required is None, unauthenticated internet exposure of an RSC endpoint is the scenario security teams prioritize first.
Who is affected in practice
You are in scope if all of the following are true:
- The deployment runs React 19 server components through one of the three named packages.
- The running build is below the patched minor for its line.
- Untrusted clients can reach RSC-generating routes (typical for public web apps).
You are out of scope when the advisory's exclusions apply:
- No server — static export or purely client-rendered SPA with no RSC pipeline.
- No RSC-capable bundler — legacy Pages Router apps that never invoke server component transport (still patch
nextfor other reasons, but this CVE is specific to RSC transport).
Teams mixing edge and Node runtimes should check both deploy artifacts. Agents often generate a Dockerfile that npm ci's once in CI and promote the same layer to production; a single stale react-server-dom-webpack there inherits the bug everywhere that image runs.
Framework and bundler map
Most developers never declare react-server-dom-webpack directly. It arrives transitively:
| Stack | Typical transport package | What to verify after upgrade |
|---|---|---|
| Next.js App Router | Often react-server-dom-webpack via next + react | Lockfile + deployed server bundle |
| Turbopack dev / RSC experiments | react-server-dom-turbopack | Dev-only servers still execute deserialization |
| Parcel RSC plugins | react-server-dom-parcel | Less common but same version bands |
When a coding agent runs npx create-next-app@latest, the generated package.json may show only next and react. Treat npm ls as mandatory: the vulnerable package can sit three levels deep. Monorepo tools (pnpm, yarn berry) dedupe differently; one workspace package on 19.2.8 can poison a shared deploy if the server build pulls that workspace.
Why "rare" still gets a critical flag
Vendors qualify bugs as rare when the vulnerable code path needs an unusual combination of features. Security teams still patch urgently because:
- Preconditions may be common on App Router hosts even if exploitation is finicky—public RSC endpoints are normal.
- Defense automation (scanners, agent deploys) may accelerate once a proof of concept appears; the advisory does not claim exploitation yet, but CVSS 9.5 assumes worst-case impact if it lands.
- Deserialization flaws historically age poorly: today's "multiple typed arrays" constraint could broaden as researchers study the transport format.
If you operate a bug bounty or red team program that lets agents hit staging, treat staging RSC hosts as production-equivalent for this CVE until versions are confirmed patched.
npm overrides when transitive deps lag
When a framework release has not yet bumped its pinned transport version, maintainers sometimes document an overrides (npm) or resolutions (yarn) block forcing patched minors. Pattern:
"overrides": {
"react-server-dom-webpack": "19.2.9"
}
Only add overrides after you confirm the patched minor matches your React line—do not jump major versions via override. Re-run your test suite focusing on server actions, streaming SSR, and any custom flight proxies agents added.
Document the override in your security runbook so the next agent-generated PR does not delete it as "unnecessary noise."
What to run today
Inventory
npm ls react-server-dom-webpack react-server-dom-turbopack react-server-dom-parcel
Run in:
- Production monorepos and marketing sites
- Internal admin tools agents scaffolded with App Router
- Preview deployments and "toy" demos that nonetheless sit on corp network
Record resolved versions. If npm prints (empty) but next is present, inspect node_modules/next/package.json dependencies or use npm ls next and follow the tree.
Upgrade path
- Bump the
react-server-dom-*package your framework documents, or upgradenext/ framework to a release that depends on patched React transport (verify in lockfile after install). - Delete cached
node_modulesin CI when lockfiles change; agents sometimes commit lockfiles without reinstalling locally. - Redeploy server and edge targets; RSC fixes are server-side deserialization — clients alone cannot compensate.
Signs you were targeted
The advisory does not document in-the-wild exploitation. Reasonable monitoring ideas:
- Unexpected server process spawning from Node hosting RSC
- New post-deserialization errors followed by shell activity in the same container
- Surges in 5xx on RSC flight endpoints with unusually large binary bodies
Treat these as generic signals, not confirmation.
What this means if you run AI coding agents
Coding agents routinely bootstrap Next.js with App Router, add server actions, and wire MCP backends behind the same Node process. Three habits raise risk after CVE-2026-126187:
- Unreviewed
package-lock.json— agents pin dependencies faster than humans read advisories. A repo generated in October 2026 may still resolve[email protected]. - "Deploy preview" sprawl — ephemeral URLs still execute RSC on the public internet. They belong in the same patch wave as production.
- Copied templates — skills and starter kits that vendor a full
node_modulestree propagate vulnerable transport packages silently.
Concrete workflow:
- Add
npm ls react-server-dom-*to CI after agent PRs merge. - Pair patching with web and transport reviews for anything that exposes server actions to anonymous users.
- When agents add image optimizer or edge routes, remember unrelated mitigations like Cloudflare's emergency WAF rules for other Next.js issues do not fix deserialization in RSC transport — patch the React packages.
Agents that only edit Python or Rust still matter if they touch a JavaScript monorepo submodule. Scan the whole workspace, not only the language the agent claims to specialize in.
What Beam can and cannot do here
Beam watches local agent actions — shell commands, file edits, credential-shaped strings — on developer machines. It does not terminate vulnerable RSC requests on a remote host, does not patch node_modules, and does not sit in the HTTP path between browsers and your Next.js server.
Where Beam still helps:
- PreToolUse-style denials (Claude Code, Codex) can block an agent from running destructive
curlexfil tests against production without you approving them. - Skill and MCP scans catch some supply-chain patterns before agents pull a stale starter kit — heuristic, not a guarantee the kit's lockfile is current.
- Local observability records if an agent attempted to
npm publishor overwrite deployment keys after generating a vulnerable app — useful during incident triage, not prevention of RCE itself.
Limits: Beam is not a WAF, not a dependency bot, and not kernel isolation for Node.
Related reading
- AI agent web and transport security — boundary checks for agent-built HTTP surfaces
- Cloudflare emergency WAF and Next.js paths — separate CVE class; do not confuse with RSC patching
- Node.js October 2026 security release for MCP servers — same "stale nested dependency" hygiene pattern
- Monitoring Railway-hosted apps — if agents deploy full-stack demos to PaaS
- Mongoose CVE-2026-125120 — another November 10 critical npm advisory agents might miss while focused on frontend deps
- CVE-2026-122006: Rails Active Storage ImageMagick — same agent-scaffold patch hygiene pattern on the Ruby stack
Primary sources: GitHub Advisory GHSA-xqc2-xf4c-x3h3, React release v19.2.9, CVE-2026-126187 on GitHub.
Frequently asked questions
What is CVE-2026-126187?
It is a critical React Server Components deserialization flaw enabling unauthenticated RCE on affected react-server-dom-* versions when crafted payloads use the multiple typed-array pattern described in the advisory.
Which npm packages must I upgrade?
All three transport packages share the same version bands: upgrade to 19.0.9, 19.1.10, 19.2.9, or 19.3.1 matching your React line.
Is my client-only app safe?
If you truly do not run a server or RSC-capable bundler, the advisory states you are not affected by this issue.
How do I verify versions in CI?
Run npm ls react-server-dom-webpack (and siblings) on every merge that touches JavaScript lockfiles; fail the build when resolved versions fall below patched minors.
Does this overlap with Brotli or image optimizer CVEs?
No. Other Next.js-related advisories and WAF rules address different code paths. CVE-2026-126187 is specific to RSC transport deserialization.
Should agents rotate secrets after patching?
Patching removes the vulnerability going forward. Rotate secrets only if you have evidence of compromise; the advisory does not claim active exploitation.
Version numbers, CVSS, and package names match the GitHub Advisory Database and React release tags as of November 10, 2026.