Every npm install is an act of trust — trust that the packages you are pulling in are what they claim to be. For roughly twelve months, North Korea’s most prolific financial threat actor quietly violated that trust on a massive scale. On July 29, 2026, Amazon Threat Intelligence published research formally attributing a chain of npm supply chain attacks to Sapphire Sleet (also tracked as BlueNoroff, Stardust Chollima, and UNC1069 — MITRE ATT&CK Group G0082). The victims were not obscure packages. They were debug and chalk — two of the most downloaded packages in the history of software, with a combined weekly download count exceeding two billion.

If your organisation runs Node.js anywhere — in CI/CD pipelines, internal tooling, web applications, or developer workstations — this campaign touched you or came within metres of doing so.

Key Takeaways

  • Amazon confirmed on July 29, 2026 that Sapphire Sleet (North Korea) is behind the npm poisoning of debug, chalk, axios, and at least 15 other packages.
  • The campaign began in March 2025 with a test payload and escalated in September 2025 when debug and chalk were compromised — briefly reaching an estimated 10% of all cloud environments.
  • Malicious code hooked fetch, XMLHttpRequest, and wallet APIs in-memory, rewriting cryptocurrency transaction addresses before user signing.
  • npm launched publish-time malware scanning on July 28, 2026, and npm v12 now disables post-install hooks by default — but packages already on the registry predate that scanning.
  • Amazon’s Akrites initiative ($12.5M) and collaboration with OpenSSF will accelerate ecosystem-wide defences — but the maintainer-compromise attack vector remains open.
  • Indian software teams relying on self-managed npm mirrors, offline caches, or legacy CI pipelines may have missed the malicious window versions entirely.

A Year-Long Campaign That Started With a Test Run

Understanding this attack requires tracing it from its beginning, not its disclosure. According to Amazon’s research, published on the AWS Security Blog, the campaign’s earliest confirmed artefact is the compromise of a low-traffic package called typo-crypto in March 2025. Amazon assesses this as a test run — a controlled experiment using a package with few watchers to validate the malware’s delivery mechanism and obfuscation before deploying it against high-profile targets.

It worked. Six months later, in September 2025, Sapphire Sleet used identical tradecraft against debug and chalk. In both cases, the threat actor did not hack npm’s infrastructure. They socially engineered a trusted package maintainer, gained publishing credentials, and pushed a poisoned update that appeared entirely legitimate at the registry level. Within two hours of the update going live, the malicious version had spread to an estimated 10% of cloud environments — a figure that speaks to how deeply these foundational packages are embedded in the global software supply chain.

The campaign continued into March 2026 with the compromise of axios, one of the most widely used HTTP clients in the Node.js ecosystem. The Hacker News reported that Microsoft has independently attributed the axios compromise to Sapphire Sleet as well, noting overlaps with activity tracked as UNC1069, CageyChameleon, and CryptoCore. By June 2026, Microsoft documented the same group poisoning 144 packages in the @mastra AI framework scope — compromising them in an automated 88-minute blitz. In total, at least 18 packages across these campaigns have been confirmed as compromised.

Technical Breakdown: How the Malware Actually Worked

Sapphire Sleet’s tooling evolved across each campaign. Here is what the technical evidence shows for each stage:

Package / Date Mechanism Payload Goal
typo-crypto (Mar 2025) Fake core.js file; base64/XOR obfuscation (key: 01042025) Stage-2 OS-specific payload from C2 (npmjs[.]store / 216.74.123.126)
debug + chalk (Sep 2025) In-memory hook of fetch, XMLHttpRequest, wallet APIs; no persistence; no post-install scripts Rewrite crypto transaction addresses before user signing
axios (Mar 2026) npm post-install hooks (now disabled in npm v12) Credential / environment harvesting

The debug and chalk payload is technically striking for what it chose not to do. It avoided any file-system writes or persistence mechanisms — features that would have triggered traditional endpoint security. Instead, it operated entirely in memory, patching browser-side JavaScript APIs at runtime. This is consistent with MITRE ATT&CK T1195.002 (Compromise Software Supply Chain) and T1027 (Obfuscated Files or Information). The environment-awareness built into the malware — delaying execution unless it detected a real developer or production context — further stymied sandbox analysis.

The C2 infrastructure used npmjs[.]store (a convincing lookalike for the legitimate npm registry) and IP 216.74.123.126. The XOR key 01042025 embedded in the typo-crypto payload appears to reference a date — April 1, 2025 — which may mark an internal milestone for the group.

Attribution: Why Amazon Points to Sapphire Sleet

Amazon’s attribution carries a medium confidence assessment — the standard threshold for declaring a nation-state actor when code reuse and infrastructure overlap are present but full forensic proof is absent. The linking evidence includes shared command-and-control infrastructure patterns, overlapping obfuscation tradecraft across campaigns, consistent “socially engineer a maintainer, then publish a poisoned update” methodology, and code-level similarities to known Sapphire Sleet tooling.

Google’s Threat Analysis Group independently attributed the axios campaign to UNC1069 (the same group under a different tracking name), citing the WAVESHAPER.V2 backdoor and use of AstrillVPN infrastructure. Microsoft’s attribution to Sapphire Sleet/CryptoCore adds a third independent data point. BleepingComputer’s coverage notes this cross-vendor convergence is unusually strong for a medium-confidence claim.

Sapphire Sleet has an established history of financial theft: the group is linked to the 2016 Bangladesh Bank heist, the Ronin Network cryptocurrency theft, and the 2025 Bybit breach. The Recorded Future News notes that DPRK cyber operations fund an estimated 40% of Pyongyang’s weapons programme — making every dollar stolen from a developer’s crypto wallet directly relevant to geopolitical risk.

What You Should Do Now: The Sanjay Seth Defence Playbook

Supply chain attacks are uniquely difficult because the threat is baked into a trusted channel. There is no firewall rule that blocks a legitimate package manager pulling a compromised-but-signed update. Defence requires process, not perimeter. Here is what I advise clients — and what we covered in our earlier analysis of the TeamPCP supply chain attack applies here too:

  1. Audit your npm lock files immediately. Check package-lock.json and yarn.lock for any version of debug, chalk, or axios installed between September 1–30, 2025 (debug/chalk) or March 2026 (axios). Cross-reference against the SHA hashes published by npm post-incident.
  2. Upgrade to npm v12+. Post-install hooks — the mechanism abused in the axios attack — are now disabled by default. Do not enable them for packages that do not strictly require them.
  3. Enable npm publish-time scanning signals. As of July 28, 2026, npm runs automated malware scanning at publish time. Configure your registry (including any Nexus, Artifactory, or JFrog mirror) to pull from a verified, scanned upstream source.
  4. Pin dependencies by exact version + hash in CI/CD. Floating ranges (^, ~) are dangerous in pipelines. A poisoned patch release can silently land in your next build. Lock and verify checksums.
  5. Monitor for outbound connections to typosquat domains. Block npmjs[.]store at your DNS and firewall layer. Add the IP 216.74.123.126 to your threat intelligence blocklist.
  6. Implement Software Bill of Materials (SBOM). Zero-trust for software supply chains means knowing exactly what is running. An up-to-date SBOM, generated at build time and ingested by your vulnerability management platform, is the starting point.
  7. Review maintainer accounts for any packages you own. Sapphire Sleet’s primary entry point is the human maintainer. Enable MFA on npm publishing accounts and audit active tokens.

Why This Matters for India’s Tech Ecosystem

India is home to the world’s second-largest developer population, with hundreds of thousands of engineers building Node.js applications daily across Bengaluru, Hyderabad, Pune, and the NCR. The npm ecosystem is the backbone of India’s startup and enterprise software output. Many organisations run private npm mirrors or offline caches — environments that may have pulled the malicious versions during the September 2025 window and retained them even after the public registry was cleaned up.

CERT-In guidance on software supply chain security has historically focused on open-source licence compliance rather than integrity verification. The Sapphire Sleet campaign is a practical case study for why that needs to change. Organisations that have adopted zero-trust architecture — with strict code-signing requirements, immutable build pipelines, and network-level egress filtering — are significantly better positioned to detect or contain this class of attack.

Frequently Asked Questions

Am I at risk if I use npm but not cryptocurrency wallets?

Yes. The debug and chalk payload targeted cryptocurrency transactions, but the broader campaign (typo-crypto, axios) was designed for environment harvesting — stealing API keys, credentials, and environment variables from developer machines and CI/CD systems. Even if you hold no crypto assets, an attacker with access to your build environment can exfiltrate secrets, plant backdoors in your software, or pivot to cloud infrastructure.

Does the published fix (npm v12 disabling post-install hooks) protect me fully?

Partially. Disabling post-install hooks closes the axios attack vector. However, the debug and chalk attack used no post-install hooks at all — it operated purely at runtime through API hooking. npm’s new publish-time malware scanning is a better defence, but it only applies to packages published after July 28, 2026. Packages already on the registry require active hash verification.

How did Sapphire Sleet compromise trusted maintainers?

The exact social engineering method has not been fully disclosed. Based on Sapphire Sleet’s documented history, the group typically approaches maintainers via LinkedIn or GitHub with fake job offers, conference invitations, or “collaboration requests” that eventually lead to credential phishing or the installation of malware disguised as a legitimate tool. This is consistent with MITRE ATT&CK T1566 (Phishing) and T1078 (Valid Accounts).

Will Amazon’s Akrites initiative prevent future attacks?

The $12.5M Akrites initiative, developed in partnership with OpenSSF, focuses on AI-enabled detection of malicious code patterns at scale. It addresses the detection side of the problem. The prevention side — stopping a legitimate maintainer from being socially engineered — requires ecosystem-wide adoption of hardware security keys for npm publishing, mandatory MFA, and vigilant package governance. Akrites is necessary but not sufficient on its own.

The Bigger Picture: State-Sponsored Attackers in Your Package Manager

The Sapphire Sleet npm campaign is a watershed moment for software supply chain security. For years, supply chain attacks were framed as a low-frequency, high-sophistication threat — the kind that targeted defence contractors or critical infrastructure. The debug and chalk compromise shows that a nation-state actor is now willing to poison the most foundational layers of civilian developer infrastructure, affecting hospitals, fintech startups, e-commerce platforms, and government services alike — with no discrimination.

The response cannot be purely technical. It requires organisations to treat their dependency graph with the same seriousness they apply to their network perimeter. Every third-party package is a trust decision. Every trust decision is a potential attack surface. In a zero-trust world, the package manager belongs inside the trust boundary — not outside it.


Is Your Software Supply Chain Secure?

The Sapphire Sleet campaign proves that supply chain risk is no longer theoretical — it is active, state-sponsored, and embedded in packages your developers install every day. I help organisations across India’s NCR and beyond build zero-trust software supply chain policies, audit their CI/CD pipelines, and establish SBOM-driven dependency governance.

Request a Supply Chain Security Assessment →