Security experts have warned that a newly discovered supply chain attack targeting npm packages is still active and may already have impacted 10% of cloud environments.
On Monday, a threat actor hijacked the npm account of a well-known developer, “qix,” via social engineering, before publishing trojanized versions of popular packages.
Although these malicious versions, which contained crypto-stealing malware, were removed within just two hours, security vendor Wiz has claimed they managed to reach 1 in 10 cloud environments.
“During the short two-hour timeframe in which the versions were available for download, if they were incorporated into frontend builds and shipped as web assets, any browsers loading the affected website would execute a malicious payload that hooks network and wallet APIs in order to silently rewrite cryptocurrency recipients/approvals before signing, so that transactions would be diverted to attacker-controlled wallets,” the vendor claimed.
“Following the release of the malicious versions, our data shows that the malicious code itself could be found in at least 10% of cloud environments, present in bundles or assets.”
Read more on open source threats: Malicious Open Source Packages Surge 188% Annually
Wiz also cited research from JFrog indicating that the campaign extends beyond qix to other npm accounts.
“After the initial batch of infected packages, we identified a few more compromised accounts, including duckdb, which indicates that the campaign is still active,” the supply chain security vendor wrote.
Malicious packages included @duckdb/node-api@1.3.3, @duckdb/duckdb-wasm@1.29.2, @duckdb/node-bindings@1.3.3, and duckdb@1.3.3. The good news is that these were also removed quickly and received “almost no downloads,” according to JFrog.
No Time to Relax
Users of what is the world’s largest software registry, NPM, were urged to stay vigilant.
“Treat the list as evolving; validate against your registry/mirror and keep blocklists current,” said Wiz.
The cloud security vendor had the following advice for security teams:
- Blocklist malicious package versions in the private registry/proxy, and pin/override to known-safe versions
- Rebuild from clean caches (CI + local), clearing all caches on local development machines and CI/CD build servers to prevent any compromised dependencies from being reintroduced from a “poisoned” cache
- Issue an invalidation command for all affected JavaScript assets on the company Content Delivery Network (CDN), in order to force servers to discard cached malicious files
- Hotfix the UI by adding client-side checksums/subresource integrity (SRI) where applicable. Temporarily disable tipping/donation modules and force re-auth for wallet flows
- Hunt for malicious packages by running bundle/asset scans and reviewing signing-flow telemetry for anomalies during 13:16-15:15 UTC on September 8
- Triage by auto-flagging approvals/transfers to unexpected recipient/spender addresses in that time window and notify impacted users
- Refresh the npm blocklist daily while the campaign continues, including DuckDB and any newly reported packages
