By submitting this form, you agree to our 

attackers published malicious versions of the popular 

 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.

 – 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.

 – Multiple malicious Nx releases and plugins were pushed over ~2 hours; within hours, npm removed them and 

2FA required for all packages and publishing moved to npm’s Trusted Publisher

, and the window, though brief, was enough to 

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).

Cloudsmith integrates this data feed via 

, providing hourly checks against the OpenSSF database. When an already cached or a newly uploaded package is detected as malicious, Continuous Security works with 

 (EPM) to automatically flag and quarantine it, preventing the harmful software from entering your builds.

Cloudsmith offers this capability as a part of our 

 (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.

: EPM enforces organization-wide rules automatically upon detection (no manual triage to start protecting builds).

: OpenSSF’s open database aggregates cross-ecosystem reports in the OSV schema, which Cloudsmith consumes directly.

Enable EPM and add a Malicious Package policy

 (OSV/OpenSSF source). This is the switch that turns detection into 

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.)

: 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.

AI-assisted malware isn’t hypothetical anymore, it’s in mainstream OSS supply chains. Cloudsmith’s 

 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.

Claire McDyre

Product Manager

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

Cloudsmith now detects malicious packages using data from OSV.dev and the OpenSSF Malicious Packages project so you can 

 packages designed to attack your supply chain 

Below is a quick primer on malicious packages, how Cloudsmith protects customers from malware with 

 (EPM) policy-as-code, and what’s next.

 is an artifact published to a public registry (npm, PyPI, RubyGems, etc.) that’s intentionally crafted to harm users or systems. Unlike a vulnerability (a flaw to be fixed), this is 

: credential theft, data exfiltration, backdoors, cryptominers, or build-pipeline compromise — delivered as a normal-looking dependency.

 for malware (it “rides” the OSS dependency graph via a compromised dependency into apps and CI/CD; more on that below).

While traditional malware often arrives via email attachments, web drive-bys, or exploit kits, 

 differ. Attackers publish them to registries (or compromise maintainers) so that 

 (CI, package managers) do the installation work for them, shifting the battleground to developer workflows and dependency resolution.

Software packages as delivery vehicles for malware isn’t a new thing. The 2018 

 incident was an early wake-up call: a trusted package was weaponized through a hidden dependency to target a cryptocurrency app. The threat has only grown. In mid-2025, 

researchers uncovered a coordinated malware campaign on npm

 attributed to North Korean threat actors, involving dozens of malicious packages disguised as developer tools. These packages, collectively downloaded thousands of times, deployed multi-stage payloads and backdoors like 

. Even as registries introduce stronger security controls, attackers continue to adapt.

 (OpenSSF), maintains a public, comprehensive, cross-ecosystem database of reports on malicious software packages (e.g., from npm, PyPI, RubyGems). It collects detailed intelligence on malicious packages—such as account takeover attacks, dependency confusion, and malware embedded via post-install hooks—and makes this information openly available using the 

As of August 2025, the database contains ~35,000 malicious package reports.

, providing hourly checks against the OpenSSF database. When a malicious package is found, Continuous Security works with 

 Blocking malicious packages at the source prevents them from ever reaching your systems.

Prevent attackers from compromising builds or slipping backdoors into production.

 Guardrails reduce risk without slowing teams down.

Catching threats before they’re integrated saves time, effort, and reputational risk.

Meet compliance and customer expectations: 

Support audits and build trust with security-conscious buyers.

Tap into a community-maintained feed of verified malicious packages across major ecosystems.

As attacks adapt, so will Cloudsmith. We’ll continue to expand detection by adding more threat intelligence sources, richer context and deeper automation in EPM. Upcoming work includes incorporating deps.dev to surface package quality and maintainability data, and adding more community feeds like OSV.dev - a great example of the open source community working together to solve supply chain security challenges. 

We’re also exploring ways for Enterprise customers to bring their own internal threat intelligence feeds into Continuous Security, further tailoring protection to their environment. Our goal is to broaden coverage and shorten the time it takes to detect and respond to threats. If there are specific feeds or heuristics you’d like us to prioritize, let us know.

in our documentation. Interested in learning more? 


Cloudsmith Blog

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

Malicious Package Detection in Cloudsmith