CVE-2026-104853 — nx
Fix: nrwl/nx@38cd82aCVE-2026-104853 is a Path Traversal vulnerability in nx. A fix is available for nx — see the affected versions and patch details below.
Nx: Path traversal in nx migrate package-migrations extraction
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-104853.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
nxnpmDescription
Summary
nx migrate reads each target package's nx-migrations.migrations value from its manifest and extracts the referenced file to a path built by joining that value onto a temporary directory. The value is never validated, so a package whose migrations field contains .. segments (or an absolute path) steers the extraction to write outside the temporary directory. A hostile package — or any package pulled in transitively through a trusted package's packageGroup — can write attacker-controlled content, or truncate an existing file, anywhere the running user can write. This happens during migration planning, before the user reviews the migration list and before --run-migrations, so it does not require the user to approve or execute anything.
Most workspaces need no action. By default nx migrate does not run the nx installed in your workspace — it installs nx@latest into a temporary directory and performs the upgrade planning, including this extraction, with that copy. Now that a patched nx is the latest release, a default nx migrate run is unaffected whatever version the workspace has installed. The installed version only runs, and is only then exposed, when that hand-off is bypassed — see Remediation.
Severity
Exploitable when the victim runs nx migrate against a package the attacker controls, directly or through a trusted package's packageGroup. The primary impact is a file write with attacker-controlled content and no path confinement; overwriting an auto-loaded file (a shell rc, a git hook, a CI script) escalates that write to code execution. There is no known evidence of exploitation in the wild.
Affected & Patched Versions
| Package | Vulnerable | Patched |
|---|---|---|
nx | >= 13.10.0, < 22.7.10; >= 23.0.0, < 23.2.1 | 22.7.10, 23.2.1 |
Every version in the ranges above is affected. The lower bound is 13.10.0, the first release where nx migrate extracted a package's migrations file from its tarball; earlier versions resolved migrations without that extraction.
[!IMPORTANT]
nx migratenormally fetches and runsnx@latestrather than the nx installed in your workspace. The ranges above therefore say where the vulnerable code ships, not who is exposed — it only runs when that hand-off is bypassed.
Remediation
If you run nx migrate normally, there is nothing to do. It resolves and runs the latest nx, which is patched, so your workspace's own nx version does not matter for this flaw.
Upgrade only if you bypass that hand-off and run the workspace's nx instead — that is, if you set NX_USE_LOCAL or NX_MIGRATE_USE_LOCAL, pin NX_MIGRATE_CLI_VERSION to an affected version, resume an existing run with --run-id, or run where the temporary install fails and nx migrate falls back to the local nx. In those cases upgrade to 22.7.10 (22.x line) or 23.2.1 (23.x line) or later:
nx migrate 23.2.1
The fix is a drop-in — no configuration changes are required, and no legitimate migrations value is affected (real packages reference ./migrations.json or another path within their own directory, all of which remain valid). Either way, do not run nx migrate against packages, or packageGroup members, that you do not trust.
Details
While planning an upgrade, nx migrate extracts each target package's migrations file to a destination built by joining the package's own nx-migrations.migrations value onto a temporary directory. That value is read from the manifest without validation, and it is handled asymmetrically: the name Nx matches against the archive entries is normalized (so its .. segments collapse), while the destination path it writes to is a raw join that keeps the .. segments and resolves outside the temporary directory. Because the attacker controls the tarball, they name their entry to equal the normalized form; the match then succeeds and the bytes are written to the un-normalized, escaping destination. The normalization is not a defence — it only dictates what the attacker must name their entry.
The same value also seeds the directory used for prompt-file extraction, which has the same shape, so both writes are steerable from the one field.
Two distinct primitives fall out of this:
- Truncation — the destination write stream is opened, and truncates, before any tar entry is inspected. So a package that points
migrationsat an existing file empties that file even when no tar entry matches — no crafted archive required. - Controlled write — when a tar entry's name matches, its bytes are written to the escaping destination. The extractor performs no path containment of its own.
Credits
- Arkadiusz Marta (RE:SOURCE) — Reporter
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | nx | ≥ 13.10.0&&< 22.7.10 | 22.7.10npm install nx@22.7.10 |
| 📦npm | nx | ≥ 23.0.0&&< 23.2.1 | 23.2.1npm install nx@23.2.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for nx, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update nx to 22.7.10 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-104853 is resolved across your whole dependency graph.
Workarounds
Resolve every user-supplied path to its canonical form and reject anything that escapes the intended directory, and run the component under an account that has no read or write access outside the directory it legitimately serves.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
This issue affects the nx migrate planning path. In Red Hat products where Nx appears in source manifests (including Grafana, Ansible Automation Platform UI components, and related offerings), Nx is used only as a build-time or development dependency, is not shipped for customer use, and nx migrate is not invoked as…
Red Hat is not aware of any mitigation or workaround that addresses this vulnerability at this time. Customers are advised to apply the relevant security update once available.Source: Red Hat security advisory for CVE-2026-104853 (CC BY 4.0)
Frequently Asked Questions
Is CVE-2026-104853 in your dependencies?
Find it across npm, including transitive dependencies.