NX npm Supply Chain Attack: How Cloudsmith Would Have Contained the Blast Radius

On August 26, 2025, attackers published malicious versions of the popular Nx build system and several plugins to npm, abusing a post-install script (telemetry.js) that ran on Linux and macOS to sweep developer machines and CI for secrets (SSH keys, GitHub/npm tokens, API keys, crypto wallets). Uniquely, the payload also tried to co-opt local AI CLI tools (Claude, Gemini, q) to help with recon and exfiltration, one of the first documented cases of malware doing so. 

What happened (quick timeline)

  • Aug 21 – A vulnerable GitHub Actions workflow was introduced in the Nx repo; although reverted in master on Aug 22, an outdated branch was later exploited to steal a GITHUB_TOKEN with read/write perms and ultimately the npm publish token.
  • Aug 26 (evening, EDT) – Multiple malicious Nx releases and plugins were pushed over ~2 hours; within hours, npm removed them and revoked publish tokens.
  • Aug 27 – Nx maintainers tightened controls: 2FA required for all packages and publishing moved to npm’s Trusted Publisher mechanism (no more npm tokens). 

Impact

Nx sees ~4M weekly downloads, and the window, though brief, was enough to leak significant credentials. Wiz observed 1,000+ valid GitHub tokens, dozens of valid cloud and npm credentials, and ~20,000 files exfiltrated; execution was seen on developer machines (often via the Nx VS Code extension) and in CI (e.g., GitHub Actions). 

How Cloudsmith would have helped

Two things

  1. Flag malicious packages.
  2. Do something when they’re found.

Cloudsmith integrates this data feed via OSV.dev into Continuous Security, providing hourly checks against the OpenSSF database. When an already cached or a newly uploaded package is detected as malicious, Continuous Security works with Enterprise Policy Management (EPM) to automatically flag and quarantine it, preventing the harmful software from entering your builds.

Cloudsmith offers this capability as a part of our Enterprise Policy Management (EPM) feature, a programmable policy-as-code layer that controls the security, compliance, and flow of artifacts across the software supply chain.

When a new threat is discovered that affects an artifact in your workspace, Continuous Security will flag it via EPM without the need for a full manual or scheduled re-scan.

In the Nx incident, entries for nx and related @nx/* packages appeared in the OpenSSF/OSV malicious-package feed within ~24 hours of first detection (e.g., MAL-2025-41443 for npm/nx, plus @nx/devkit, @nx/node, @nx/workspace, and others). With Cloudsmith’s hourly ingestion, these packages would have been automatically flagged and quarantined, shrinking exposure time and limiting downstream blast radius.

You can check out a deeper dive of how EPM uses OSV to detect and block malicious packages here.

Why this matters

  • Stops the spread early: Malicious packages are blocked before they reach dev machines or CI.
  • Policy-as-code response: EPM enforces organization-wide rules automatically upon detection (no manual triage to start protecting builds). 
  • Community-driven intel: OpenSSF’s open database aggregates cross-ecosystem reports in the OSV schema, which Cloudsmith consumes directly. 

What Cloudsmith customers should do now

  1. Enable EPM and add a Malicious Package policy (OSV/OpenSSF source). This is the switch that turns detection into automatic quarantine for new downloads.
  2. Understanding the defense in depth approach: A malicious package can be ingested into a build pipeline before threat intelligence sources like OpenSSF or OSV publish indicators, creating a blind spot during which the artifact remains undetected. Mitigating this exposure requires a defense-in-depth strategy: enforce ingress controls at the artifact repository level (e.g., Cloudsmith) to block known and suspicious packages, and implement downstream detection via CI scanners and endpoint monitoring to identify and remove compromised dependencies already in use. (This is about realistic risk staging: block new ingress at Cloudsmith; find and purge what’s already inside with endpoint/CI scans.)
  3. Remediate broadly: Even though npm has removed the bad Nx versions, follow the incident guidance (rotate tokens/keys, search for s1ngularity-repository* and results.b64, clean shell startup files, audit CI). Wiz and the Nx advisory provide concrete steps.

Closing thought

AI-assisted malware isn’t hypothetical anymore, it’s in mainstream OSS supply chains. Cloudsmith’s Malicious Package Detection + EPM gives you an automated, policy-driven first line of defense that can turn multi-hour chaos into a contained non-event. Pair it with good credential hygiene and CI hardening—and insist on provenance/Trusted Publisher for your own releases, just as the Nx team has done post-incident.

Keep up to date with our monthly newsletter

By submitting this form, you agree to our privacy policy