The chalk and debug npm Supply Chain Attack

What happened

A phishing email gave the attacker control of a maintainer's npm account, and the attacker published poisoned releases of 18 packages. Socket reports that the email looked like a 2FA reset notice from support@npmjs.help. It said that old 2FA credentials would soon lock the account. Aikido reports that the domain was registered on 5 September 2025, three days before the attack. A second maintainer was targeted the same way later on 8 September, and that led to a bad release of proto-tinker-wc.

These packages format text and handle colors in terminals. Their entry files had no network code. The poisoned files added code that wraps fetch, XMLHttpRequest and window.ethereum.request. Wiz also lists Solana signing methods. The code scans traffic for wallet addresses on several blockchains. It replaces the address with a look-alike address that the attacker controls. It also rewrites token approvals and swap recipients on common exchanges.

The code runs in a browser. It matters most when a web application bundled a bad version into its frontend code. Wiz says the malware has no persistence and no telemetry. Its impact ends when the script stops running.

The exposure window was short. Wiz puts the window at about two hours on 8 September 2025, from about 13:16 UTC to about 15:15 UTC. It reports that the code reached about 10 percent of the cloud environments it monitors. It says reported financial loss was minimal. The remediation work was large, because 99 percent of those environments contained at least one targeted package.

Affected versions

Aikido lists these 18 bad versions. Wiz also lists bad versions of duckdb, @duckdb/node-api, @duckdb/node-bindings, @duckdb/duckdb-wasm, proto-tinker-wc and @coveops/abi.

• ansi-regex@6.2.1
• ansi-styles@6.2.2
• backslash@0.2.1
• chalk@5.6.1
• chalk-template@1.1.1
• color-convert@3.1.1
• color-name@2.0.1
• color-string@2.1.1
• debug@4.4.2
• error-ex@1.3.3
• has-ansi@6.0.1
• is-arrayish@0.3.3
• simple-swizzle@0.2.3
• slice-ansi@7.1.1
• strip-ansi@7.1.1
• supports-color@10.2.1
• supports-hyperlinks@4.1.1
• wrap-ansi@9.0.1

The versions before these are clean. For example, chalk 5.6.0, debug 4.4.1 and ansi-styles 6.2.1 are the last clean releases.

Indicators of compromise

• Phishing domain: npmjs.help, sender support@npmjs.help.
• Obfuscated code in bundled JavaScript that starts with const _0x112fa8=_0x180f;. Wiz gives this as a pattern to scan for.
• Code in a package entry file that wraps fetch, XMLHttpRequest or window.ethereum.request.
• For proto-tinker-wc, the changed file is dist/cjs/proto-tinker.cjs.entry.js.
• Socket publishes a long list of attacker wallet addresses on Ethereum, Bitcoin, Tron, Litecoin, Bitcoin Cash and Solana. Use its post to check them against your transaction logs.

How to check

List every installed copy of these versions, including indirect dependencies. Then search your lockfile.

npm ls --all 2>/dev/null | grep -E '(ansi-regex@6\.2\.1|ansi-styles@6\.2\.2|backslash@0\.2\.1|chalk@5\.6\.1|chalk-template@1\.1\.1|color-convert@3\.1\.1|color-name@2\.0\.1|color-string@2\.1\.1|debug@4\.4\.2|error-ex@1\.3\.3|has-ansi@6\.0\.1|is-arrayish@0\.3\.3|simple-swizzle@0\.2\.3|slice-ansi@7\.1\.1|strip-ansi@7\.1\.1|supports-color@10\.2\.1|supports-hyperlinks@4\.1\.1|wrap-ansi@9\.0\.1)'
grep -nE '(ansi-regex@6\.2\.1|ansi-styles@6\.2\.2|backslash@0\.2\.1|chalk@5\.6\.1|chalk-template@1\.1\.1|color-convert@3\.1\.1|color-name@2\.0\.1|color-string@2\.1\.1|debug@4\.4\.2|error-ex@1\.3\.3|has-ansi@6\.0\.1|is-arrayish@0\.3\.3|simple-swizzle@0\.2\.3|slice-ansi@7\.1\.1|strip-ansi@7\.1\.1|supports-color@10\.2\.1|supports-hyperlinks@4\.1\.1|wrap-ansi@9\.0\.1)' package-lock.json

Check the lockfile of each frontend that built during 8 September 2025. A bad version can sit in a bundle you already shipped, even if your lockfile is clean now. Search the built JavaScript for the pattern in the list above.

What to do now

1. Pin each package to a clean version in your lockfile and block the bad versions in a private registry.
2. Clear package caches on build servers and on developer machines. Aikido suggests npm cache clean --force.
3. Remove node_modules and reinstall from the pinned lockfile.
4. Rebuild and redeploy every frontend that built in the window. Invalidate old files on your CDN.
5. Look at signing and approval activity in the window for recipient or spender addresses that you do not know.
6. Vigilance compares a new package version with the one you trust and reports the file that gained a new capability. Here, a formatting library gained code that wraps network calls and wallet requests.

What Vigilance showed

Vigilance compares the version you trust with the new one and names the file that gained a new capability. The block below is rebuilt from the public reports in the words Vigilance prints. It is not a captured scan, because the malicious release is not redistributed.

files scanned: 70 (1 Added)

HEADS UP  1 file can now do things the old version could not. The rest changed and gained nothing.

NEW FILE   index.js
           It downloads from the internet.

Sources

1. socket.dev/blog/npm-author-qix-compromised-in-major-supply-chain-attack
2. wiz.io/blog/widespread-npm-supply-chain-attack-breaking-down-impact-scope-across-debug-chalk
3. aikido.dev/blog/npm-debug-and-chalk-packages-compromised