On September 8th, 13:16 UTC, Aikido’s intel feed detected something alarming:
A wave of updates was published to 18 widely used npm packages — but these weren’t just ordinary updates. They contained malicious code designed to hijack browser-based crypto and web3 activity.
These weren’t obscure packages either. Together, they account for over 2 billion weekly downloads.
Affected Packages
The following packages were compromised, with their approximate weekly downloads:
-
backslash(0.26m) -
chalk-template(3.9m) -
supports-hyperlinks(19.2m) -
has-ansi(12.1m) -
simple-swizzle(26.26m) -
color-string(27.48m) -
error-ex(47.17m) -
color-name(191.71m) -
is-arrayish(73.8m) -
slice-ansi(59.8m) -
color-convert(193.5m) -
wrap-ansi(197.99m) -
ansi-regex(243.64m) -
supports-color(287.1m) -
strip-ansi(261.17m) -
chalk(299.99m) -
debug(357.6m) -
ansi-styles(371.41m)
Together, these represent the backbone of many JavaScript projects, from CLIs to frameworks.
What Happened?
Attackers published new versions of trusted packages that included a malicious payload which:
- Intercepts crypto/web3 interactions in the browser.
- Silently manipulates wallet approvals and transactions.
- Rewrites payment destinations to attacker-controlled addresses.
- Does all this without raising obvious red flags for the user.
This is a classic supply chain attack. If your project depends on one of these packages, you could have unknowingly pulled in malicious code.
Example of one attached packages: is-arrayish
Normally, is-arrayish is a tiny utility package with ~70m weekly downloads.
But in the compromised version, malicious code was injected to execute in browsers, intercepting and tampering with wallet interactions.
What should have been a harmless utility effectively became a crypto-drainer.
How To Protect Yourself and Your Project
Supply chain attacks like this are hard to spot, but there are practical steps you can take to reduce risk:
1. Pin Dependencies
Don’t let your project automatically pull the “latest” version. Pin to a known safe version:
# install a specific version instead of latest
npm install chalk@4.1.2
yarn add chalk@4.1.2
This prevents your project from auto-updating to potentially malicious releases.
2. Enable Lockfiles in CI/CD
Always commit your package-lock.json or yarn.lock and enforce strict installs:
# verify lockfile consistency
npm ci
yarn install --frozen-lockfile
This ensures all environments use exactly the same versions.
3. Audit Regularly
Check your project for known vulnerable or malicious versions:
npm audit --production
yarn audit
For deeper checks, integrate tools like:
-
Snyk (
snyk test) - Aikido Safe-Chain
- OWASP Dependency-Check
4. Monitor Transitive Dependencies
Even if you trust your direct dependencies, nested ones can carry malicious code. Use:
npm ls
yarn list --pattern ansi
This reveals which versions of ansi-styles, chalk, etc. are in your dependency tree.
5. Use Security Gatekeeping in CI
Configure your CI pipeline to fail if unverified dependency upgrades are introduced.
This blocks “drive-by” dependency updates from sneaking into builds.
6. Stay Informed
- Subscribe to npm and GitHub security advisories.
- Follow trusted feeds (Aikido intel, snyk.io, etc.).
- Be cautious of sudden version bumps in usually stable libraries.
Why This Matters
The compromised packages aren’t just utilities — they are foundational dependencies in the JavaScript ecosystem.
Even if you don’t use them directly, your project may still be exposed through transitive dependencies.
That means the blast radius of this attack is enormous.
Final Thoughts
This incident is another reminder that supply chain security matters. With attackers increasingly targeting package registries, the question isn’t if but when your dependencies will be attacked.
👉 Stay vigilant.
👉 Audit your dependencies.
👉 Use tools that provide visibility into package updates.
Your project’s security depends not only on your own code — but also on the thousands of packages you rely on.
Top comments (0)