One Phished Maintainer, Four Poisoned Packages: Amazon Names North Korea in npm Supply Chain Campaign

On July 29, 2026, Amazon Threat Intelligence published a detailed attribution report linking a coordinated series of npm supply chain attacks — spanning more than a year and touching four packages with a combined weekly download count well above a billion — to Sapphire Sleet, the North Korean state-sponsored group also tracked as BlueNoroff and Stardust Chollima. The targets: debug, chalk, axios, and a smaller package called typo-crypto. If your stack runs anything built on Node.js, at least one of these is almost certainly in your dependency tree right now.

The Attack Playbook: Phish the Maintainer, Poison the Package

In each case, Sapphire Sleet used the same core technique: social-engineer a trusted maintainer using a lookalike npm domain, gain account access, and publish a malicious update. The infected versions carried wallet-draining scripts designed to scan the running environment for cryptocurrency wallets, API keys, and credentials, then exfiltrate them to attacker-controlled infrastructure.

The campaign unfolded in three phases:

• March 2025 — typo-crypto: A smaller, lower-stakes package compromised first. Amazon's analysis reads this as a proof-of-concept run — same technique, reduced blast radius while the playbook was being validated.
• September 2025 — debug and chalk: The group went big. debug carries roughly 300 million weekly downloads; chalk roughly 700 million. The malicious versions spread to an estimated 10% of cloud environments before the packages were detected, flagged, and pulled. Socket reported the attacker-controlled wallets collected approximately $600 in direct cryptocurrency theft — small because the window was short, not because the reach was limited.
• March 2026 — axios: With over 100 million weekly downloads, axios was hit using the same social engineering vector. Amazon attributes this phase to Sapphire Sleet with medium confidence.

All four compromised packages have since been remediated and safe versions are current on the npm registry. The publication of the attribution report is the news; the active threat has passed. That said, the investigation took ten months — environments that cached a poisoned version and never rotated credentials may not know it yet.

Who Is Sapphire Sleet?

Sapphire Sleet is a DPRK-sponsored unit with a long track record of targeting cryptocurrency exchanges and financial platforms to generate revenue for the North Korean government. The group is estimated to have stolen hundreds of millions of dollars across multiple campaigns involving phishing, social engineering, and custom malware. What has shifted is the targeting logic.

Attacking a cryptocurrency exchange directly means breaching a hardened perimeter with dedicated security staff. Attacking the people who maintain debug and chalk means reaching every environment that runs npm install. The package maintainer is the soft target; the downstream blast radius is enormous. This is not a novel concept in supply chain security, but executing it against packages at this download scale — and doing it successfully, at least in terms of reach — represents a meaningful operational escalation.

Why This Matters Even If You Don't Touch Crypto

The immediate payload targeted cryptocurrency wallets. But the access vector is far broader. These packages run in Node.js backends, serverless functions, CI/CD pipeline runners, Docker build environments, and cloud developer toolchains. In any of those contexts, a compromised package can read environment variables, exfiltrate .env files, capture database credentials, or phone home with AWS or cloud API keys. The Sapphire Sleet payload was crypto-focused; the next group using the same playbook will target whatever your build environment happens to hold.

Transitive dependencies make this substantially worse. You may not directly import debug, but something three levels deep in your node_modules tree almost certainly does. Most dependency audits focus on direct imports. Indirect dependencies are where supply chain attacks live, and they are significantly harder to reason about without tooling.

What To Do Now

The malicious versions are gone from the registry. The immediate priority is confirming you are not running a cached copy and that no credentials were silently exfiltrated from an affected environment during the exposure windows:

• Run npm audit across every project. It will not catch every supply chain issue, but it surfaces known-malicious versions against the advisory database. Do it in CI, not just locally.
• Commit and pin your lockfiles. package-lock.json or yarn.lock records exact versions and sha512 integrity hashes. Without a committed lockfile, each npm install can silently resolve to a different version. If your lockfile is not committed and checked in CI, fix that before anything else on this list.
• Enable registry integrity checking. npm validates package integrity against the registry's sha512 checksum when a lockfile is present. Non-lockfile installs bypass this check entirely. This is another reason lockfiles are non-negotiable in production pipelines.
• Add behavioral SCA tooling. Static advisories catch known-bad versions after the fact. Tools like Socket.dev monitor behavioral signals — new network calls, filesystem access patterns, obfuscated code — in newly published package versions and can flag anomalies before a formal advisory exists. The Sapphire Sleet packages would have triggered those signals.
• Restrict outbound network access from CI/CD runners. A build runner with unrestricted outbound internet is an exfiltration vector. Limit outbound connections to what is explicitly required: the npm registry, your artifact store, and nothing else.
• Audit secrets exposure in your build pipeline. Credentials and API keys present in build environments should be scoped to exactly the stages that need them. If a compromised npm package can read a .env file containing production database credentials, that is the actual blast radius — not just what the package's payload was explicitly written to steal.
• Rotate any credentials in scope during the exposure windows. September 2025 and March 2026 are the relevant windows. If environments running debug, chalk, or axios had cloud credentials or API keys present during those periods and no credential rotation has happened since, rotate them now.

The Bigger Picture

Amazon's ten-month investigation timeline is instructive. Supply chain compromises are often discovered quickly at the package level — the malicious version gets pulled within hours. The downstream question — which environments downloaded the poisoned version, what data was accessible, and whether anything was exfiltrated — takes far longer to answer, and in many cases goes unanswered entirely.

Nation-state actors shifting from direct intrusion to dependency poisoning is a durable trend. The npm ecosystem's trust model — open publishing, automatic propagation, deep transitive graphs — was designed for developer velocity, and it works exceptionally well for that purpose. It also means a single compromised maintainer account can reach a substantial fraction of the internet's infrastructure within hours. Treating your dependency tree as part of your attack surface, with the same rigor applied to your code, is the only realistic response.

We review the full dependency graph before pushing upstream changes into any production environment — a habit that looks like overhead until it is not.