GHSA-HRVQ-X7JP-36XV

Vulnerability from github – Published: 2026-10-05 23:28 – Updated: 2026-10-05 23:28
VLAI
Summary
Nx: Path traversal in nx migrate package-migrations extraction
Details

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 migrate normally fetches and runs nx@latest rather 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 migrations at 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
Severity
5.8 (Medium)
CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:P/VC:L/VI:H/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "nx"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "13.10.0"
            },
            {
              "fixed": "22.7.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "nx"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "23.0.0"
            },
            {
              "fixed": "23.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-104853"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-73"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-05T23:28:35Z",
    "nvd_published_at": "2026-10-02T17:17:03Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`nx migrate` reads each target package\u0027s `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 \u2014 or any package pulled in transitively through a trusted package\u0027s `packageGroup` \u2014 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.\n\n**Most workspaces need no action.** By default `nx migrate` does not run the nx installed in your workspace \u2014 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 \u2014 see Remediation.\n\n## Severity\n\nExploitable when the victim runs `nx migrate` against a package the attacker controls, directly or through a trusted package\u0027s `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.\n\n## Affected \u0026 Patched Versions\n\n| Package | Vulnerable | Patched |\n| --- | --- | --- |\n| `nx` | `\u003e= 13.10.0, \u003c 22.7.10`; `\u003e= 23.0.0, \u003c 23.2.1` | `22.7.10`, `23.2.1` |\n\nEvery version in the ranges above is affected. The lower bound is 13.10.0, the first release where `nx migrate` extracted a package\u0027s migrations file from its tarball; earlier versions resolved migrations without that extraction.\n\n\u003e [!IMPORTANT]\n\u003e `nx migrate` normally fetches and runs `nx@latest` rather than the nx installed in your workspace. The ranges above therefore say where the vulnerable code ships, not who is exposed \u2014 it only runs when that hand-off is bypassed.\n\n## Remediation\n\n**If you run `nx migrate` normally, there is nothing to do.** It resolves and runs the latest nx, which is patched, so your workspace\u0027s own nx version does not matter for this flaw.\n\nUpgrade only if you bypass that hand-off and run the workspace\u0027s nx instead \u2014 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:\n\n```\nnx migrate 23.2.1\n```\n\nThe fix is a drop-in \u2014 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.\n\n## Details\n\nWhile planning an upgrade, `nx migrate` extracts each target package\u0027s migrations file to a destination built by joining the package\u0027s 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 \u2014 it only dictates what the attacker must name their entry.\n\nThe 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.\n\nTwo distinct primitives fall out of this:\n\n- **Truncation** \u2014 the destination write stream is opened, and truncates, before any tar entry is inspected. So a package that points `migrations` at an existing file empties that file even when no tar entry matches \u2014 no crafted archive required.\n- **Controlled write** \u2014 when a tar entry\u0027s name matches, its bytes are written to the escaping destination. The extractor performs no path containment of its own.\n\n## Credits\n\n- **Arkadiusz Marta** (RE:SOURCE) \u2014 Reporter",
  "id": "GHSA-hrvq-x7jp-36xv",
  "modified": "2026-10-05T23:28:35Z",
  "published": "2026-10-05T23:28:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nrwl/nx/security/advisories/GHSA-hrvq-x7jp-36xv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-104853"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nrwl/nx/pull/36887"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nrwl/nx/commit/38cd82a0c05e8212e538bdb87ccb198d6504e58f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nrwl/nx/commit/95474ab457e8e1dbdbefad29040c166105a8fb90"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nrwl/nx/commit/de37c5ebd1852fac700d70726326236ac398af3f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nrwl/nx"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nrwl/nx/releases/tag/22.7.10"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nrwl/nx/releases/tag/23.2.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:P/VC:L/VI:H/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Nx: Path traversal in nx migrate package-migrations extraction"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.