CVE-2026-71476
JavaScript Analyse et atténuation des vulnérabilités

Aperçu

CVE-2026-71476 is a Zip-Slip / path traversal vulnerability in the Nx monorepo tool's self-hosted HTTP remote cache that allows a malicious or on-path (MITM) cache server to write arbitrary files to any location on the filesystem of machines running Nx, which can be escalated to remote code execution. It affects the nx npm package from version 20.8.0 through 22.7.6 and versions 23.0.0–23.0.1, and was introduced when the self-hosted HTTP remote cache feature was added in Nx 20.8.0. The vulnerability was reported by Lidor B. and Assaf Levkovich of Novee Security, disclosed via GitHub Advisory GHSA-vp3h-ghgh-jr7g on August 6, 2026, and fixed in versions 22.7.7 and 23.0.2. It carries a CVSS v4.0 base score of 8.7 (High) (GitHub Advisory).

Détails techniques

The root cause is improper limitation of a pathname to a restricted directory (CWE-22) combined with improper link resolution before file access (CWE-59). When Nx retrieves a cache artifact from a self-hosted HTTP remote cache server, it downloads a gzipped tar archive and extracts it using Rust's Entry::unpack() without any boundary check — the untrusted tar entry name is joined directly onto the output directory path (output_dir.join(entry_path)), allowing ../ sequences, absolute paths, and symlink/hardlink entries to escape the cache directory. Additionally, the restore step copied the entire cache directory into the workspace while following symlinks, compounding the exposure. The attack requires the target workspace to be configured to use a self-hosted remote cache (NX_SELF_HOSTED_REMOTE_CACHE_SERVER or packages such as @nx/s3-cache, @nx/gcs-cache, @nx/azure-cache, @nx/shared-fs-cache); Nx's default local cache and Nx Cloud are not affected (GitHub Advisory, Fix PR #36116).

Impact

A malicious or network-positioned (MITM) remote cache server operator can write arbitrary files to any location accessible by the Nx process on the developer or CI machine, including sensitive targets such as ~/.ssh/authorized_keys, git hooks (e.g., .git/hooks/pre-commit), shell configuration files (e.g., ~/.zshrc), or package manifests. This arbitrary file write can be directly escalated to remote code execution on the affected system. Confidentiality, integrity, and availability of the affected machine are all fully compromised upon successful exploitation (GitHub Advisory, Fix PR #36116).

Exploitabilité

There is no public proof-of-concept exploit and no evidence of active in-the-wild exploitation as of the disclosure date (Feedly). The EPSS score is 0.0, reflecting the current absence of observed exploitation activity. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires either control of the self-hosted remote cache server or a network-level man-in-the-middle position between the Nx client and the cache server, and passive user interaction (a developer or CI pipeline triggering a cache restore) (GitHub Advisory).

Étapes d’exploitation

  1. Identify a target: Locate an Nx workspace (version 20.8.0–22.7.6 or 23.0.0–23.0.1) configured to use a self-hosted HTTP remote cache via NX_SELF_HOSTED_REMOTE_CACHE_SERVER or a self-hosted cache package (@nx/s3-cache, @nx/gcs-cache, etc.).
  2. Position for attack: Either gain control of the self-hosted cache server (e.g., by compromising it or substituting a malicious server) or achieve a network-level MITM position between the Nx client and the cache server (e.g., via DNS spoofing, ARP poisoning, or exploiting disabled TLS verification with NODE_TLS_REJECT_UNAUTHORIZED=0).
  3. Craft a malicious tar archive: Create a gzipped tar archive containing entries with path-traversal sequences (e.g., ../../.ssh/authorized_keys), absolute paths (e.g., /etc/cron.d/evil), or symlinks/hardlinks that point outside the intended cache directory.
  4. Serve the malicious artifact: When the Nx client requests a cache artifact, respond with the crafted tar archive instead of a legitimate cache entry.
  5. Trigger cache restore: Wait for or induce a developer or CI pipeline to run an Nx command that triggers a cache hit and restore (e.g., nx build, nx test). The vulnerable extractor writes the malicious tar entries to arbitrary filesystem locations.
  6. Achieve code execution: The written file (e.g., an SSH authorized key, a git hook, or a shell RC file) is subsequently executed by the user or system, granting the attacker remote code execution (GitHub Advisory, Fix PR #36116).

Indicateurs de compromis

  • File System: Unexpected or modified files in sensitive locations such as ~/.ssh/authorized_keys, .git/hooks/pre-commit, ~/.zshrc, ~/.bashrc, /etc/cron.d/, or other locations outside the Nx workspace root or cache directory; new or modified files with timestamps coinciding with Nx cache restore operations.
  • File System: Symlinks in the Nx cache directory or workspace pointing to locations outside the workspace root.
  • Logs: Nx or CI build logs showing cache restore operations from an unexpected or newly configured remote cache server URL; errors or warnings related to TLS certificate verification being disabled (NODE_TLS_REJECT_UNAUTHORIZED=0).
  • Network: Outbound connections from developer or CI machines to unfamiliar or unexpected cache server endpoints; HTTP responses from the cache server with unusually large or malformed tar archives.
  • Process: Unexpected processes spawned following Nx cache restore operations (e.g., reverse shells, curl, wget, or script interpreters initiated by git hooks or shell RC files).

Atténuation et solutions de contournement

Upgrade the nx package to version 22.7.7 or 23.0.2 (or later); the patched extractor uses Rust's unpack_in for containment and requires no configuration changes (GitHub Advisory). Workspaces using the deprecated self-hosted cache packages (@nx/s3-cache, @nx/gcs-cache, @nx/azure-cache, @nx/shared-fs-cache and their @nx/powerpack-* predecessors) are not fully remediated by upgrading nx alone — these packages are deprecated and should be migrated to Nx Cloud or the self-hosted OpenAPI/HTTP remote cache per the deprecation guidance at https://nx.dev/docs/reference/deprecated/self-hosted-cache-packages. As an interim measure, ensure all remote cache server connections use authenticated HTTPS with valid certificates (avoid NODE_TLS_REJECT_UNAUTHORIZED=0), and restrict network access to the cache server to trusted hosts only (Fix PR #36116).

Réactions de la communauté

The vulnerability was reported by Lidor B. and Assaf Levkovich of Novee Security and disclosed responsibly through GitHub's security advisory process. The Nx maintainer (FrozenPandaz) published a detailed fix PR (#36116) with extensive regression tests and a follow-up TLS hardening PR (#36132). No significant broader media coverage or notable social media reactions have been identified beyond the GitHub advisory and standard vulnerability aggregator listings (GitHub Advisory).

Ressources additionnelles


SourceCe rapport a été généré à l’aide de l’IA

Apparenté JavaScript Vulnérabilités:

Identifiant CVE

Sévérité

Score

Technologies

Nom du composant

Exploit CISA KEV

A corrigé

Date de publication

CVE-2026-71476HIGH8.7
  • JavaScript logoJavaScript
  • @nx/gcs-cache
NonOuiAug 06, 2026
CVE-2026-71437MEDIUM6.5
  • JavaScript logoJavaScript
  • mermaid
NonOuiAug 06, 2026
CVE-2026-71439MEDIUM5.3
  • JavaScript logoJavaScript
  • mermaid
NonOuiAug 06, 2026
CVE-2026-71498MEDIUM5.1
  • JavaScript logoJavaScript
  • re2
NonOuiAug 06, 2026
CVE-2026-71438LOW2.4
  • JavaScript logoJavaScript
  • mermaid
NonOuiAug 06, 2026

Évaluation gratuite des vulnérabilités

Évaluez votre posture de sécurité dans le cloud

Évaluez vos pratiques de sécurité cloud dans 9 domaines de sécurité pour évaluer votre niveau de risque et identifier les failles dans vos défenses.

Demander une évaluation

Obtenez une démo personnalisée

Prêt(e) à voir Wiz en action ?

"La meilleure expérience utilisateur que j’ai jamais vue, offre une visibilité totale sur les workloads cloud."
David EstlickRSSI
"Wiz fournit une interface unique pour voir ce qui se passe dans nos environnements cloud."
Adam FletcherChef du service de sécurité
"Nous savons que si Wiz identifie quelque chose comme critique, c’est qu’il l’est réellement."
Greg PoniatowskiResponsable de la gestion des menaces et des vulnérabilités