01 · Briefing · what happened

North Korea poisoned the code millions of apps pull in without looking

Cybersecurity 2 min 11 sources

Amazon traced a run of npm supply-chain attacks to a North Korean group that hijacked some of open-source's most-used packages - reaching an estimated 10% of cloud environments in two hours.

10%

of cloud environments

reached by debug and chalk in two hours

100M+

weekly downloads

of axios, hit in March 2026

18

malicious npm packages

flagged Sunday, delivering a remote-access trojan

500+

fraudulent certificates

from the 2011 DigiNotar breach; the authority did not survive

At a glance

Amazon tied a run of npm supply-chain attacks to Sapphire Sleet, a North Korean group.
Debug and chalk were poisoned in September 2025, reaching an estimated 10% of cloud environments in two hours.
In March 2026 the group hit axios, a package with over 100 million weekly downloads.
Each time, they socially engineered the maintainer, then pushed a malicious update that projects auto-pulled.
The attribution is medium-confidence; a smaller 2025 compromise looks like a rehearsal.
CISA issued fresh open-source and SBOM guidance the same week to map buried dependencies.

Forces in play

Supply-chain risk High

top packages poisoned, more landing weekly

Auto-update habit High

pulling latest silently spreads a poisoned version

Provenance push Building

CISA SBOM and open-source guidance this week

Attribution clarity Steady

Amazon links the campaigns, but medium-confidence

In play Sapphire Sleet (BlueNoroff) — North Korean group behind the npm compromises Amazon Threat Intelligence — traced and attributed the campaign npm maintainers — socially engineered into publishing poisoned updates CISA — issued open-source and SBOM guidance

How it unfolded

Mar 2025 typo-crypto poisoned - a rehearsal
Sep 2025 debug and chalk hit; 10% of cloud environments in two hours
Mar 2026 axios compromised - 100M+ weekly downloads
This week 18-package RAT campaign flagged; CISA issues guidance

Full briefing

Amazon’s threat-intelligence team said this week it traced a run of software supply-chain attacks to Sapphire Sleet, a North Korean group also known as BlueNoroff [1][4]. The target was npm, the registry where JavaScript developers pull in ready-made code. A single popular package there can sit under millions of apps, so poisoning one reaches everyone downstream [1].

The group hit some of the most-used packages in the ecosystem. Debug and chalk were compromised in September 2025, reaching an estimated 10% of cloud environments within two hours [1]. In March 2026 it hit axios, a library with over 100 million weekly downloads [2]. Amazon’s attribution is medium-confidence, based on shared tactics and command infrastructure [1].

The playbook was the same each time. The attackers socially engineered a package’s maintainer - the person who controls it - then published a malicious update, which any project set to auto-pull the latest version received [2]. The malice usually hid in post-install scripts, not the visible code, and the group behaved like a real maintainer for weeks first [2]. Amazon believes a smaller compromise, typo-crypto in March 2025, was a rehearsal a full year before axios [3].

Fresh cases keep landing. On Sunday, researchers flagged 18 malicious npm packages delivering a remote-access trojan - malware that hands an attacker remote control [5]. They targeted developers using Alibaba tools, and one package copied the name of a private Alibaba library [5]. Two “joyfill” packages were caught running the same kind of trojan when imported into a Node.js app [6].

CISA, the US cyber-defense agency, put out guidance this week on securing open-source software and on SBOMs [7][8]. An SBOM is a software bill of materials - an ingredient list showing not just what you ship but what those components depend on [9]. The problem it names is old: the log4shell and xz-utils incidents both turned on a buried dependency nobody was watching [7].

All of this rests on trust anchors. The same week, analysts revisited the web’s certificate roots - the handful of authorities that underwrite the padlock in your browser [10]. History shows how fragile the base is: when the Dutch authority DigiNotar was breached in 2011 and more than 500 fraudulent certificates were issued, it did not survive [10]. Whether the anchor is a maintainer’s account or a root certificate, the pattern is one - trust flows down from it, and so does its collapse [10][11].

02 · Lesson · why it matters

The one name that everything downstream trusts

You can't check every line of code you run, so you trust the name it came from - and that name is the thing worth stealing.

How it works

You import code you didn't write
You trust it because it traces to a trusted name
That name is an anchor - a maintainer account or signing key
Compromise the anchor, and everyone who trusted it inherits the poison at once

The twist

Trust in computing isn't a web of separate judgments - it's a chain that bottoms out in one anchor, so forging the anchor collapses everything downstream at once.

Where you've seen this

Web certificates

your browser trusts a site because a root authority signed it; break the root and every chained site is suspect

App stores

you trust an app because the platform signed it, not because you read the code

A notarized document

you trust the paper because you trust the notary's stamp, not the signer

The catch

You can't verify all the way down, so something at the base is always trusted on faith - the fix isn't to remove the anchor but to see it and be able to replace it fast.

Full lesson

The thing nobody actually reads

A developer types a command and pulls in code called axios. Over a hundred million projects a week do the same. Almost none of them read it. They can’t - a modern app leans on hundreds of packages, and those lean on hundreds more.

So they don’t verify the code. They trust the name. axios comes from a known account, on a known registry, under a known package name. That is enough. And it has to be enough, because verifying everything by hand would mean nobody ever ships anything.

This is not laziness. It is the only way the system works. The whole point of a trusted name is that it lets you skip the checking.

Trust is a chain, and it bottoms out somewhere

Follow the trust down and it forms a chain. You trust the app because you trust the package. You trust the package because you trust the maintainer’s account. You trust the account because you trust the registry that hosts it.

The web does the same thing with padlocks. Your browser trusts a website because a certificate authority signed its certificate. It trusts that authority because the authority’s root certificate was built into your browser years ago, by someone you never met.

Every chain like this ends at an anchor - a thing you trust without proof. A signing key. A root certificate. A maintainer’s login. You don’t check the anchor. Checking it is the one thing the whole arrangement lets you avoid. That is what a root of trust is: the place where the questions stop.

The anchor is the target

Here is the turn. If trust flows down the chain, so does its collapse.

You don’t have to break a million apps one by one. You break the one thing they all trust. Compromise the maintainer’s account behind debug and chalk and push a poisoned update. Every project that pulls the latest version inherits it - an estimated tenth of cloud environments in two hours. The apps were fine. Their code never changed. What changed was the name they trusted, at the source.

The certificate world learned this the hard way. In 2011 the Dutch authority DigiNotar was breached and more than 500 fraudulent certificates were issued. That authority underwrote trust for countless sites. When it fell, it did not fall alone, and it did not survive.

The deeper the compromise sits - the closer to the anchor - the wider it spreads. A single leaf package poisons one app. A foundational one poisons everything built on it. The root itself poisons the whole tree, and it can forge the very stamps you would use to check.

Why your ordinary defenses only go so far

The natural fix is to stop auto-pulling: pin your dependencies to a version you have checked, and verify each update’s signature before you take it. That works, and it matters. It stops a poisoned new version from sliding in unnoticed.

But notice what it leans on. You verify a signature against the anchor. If the anchor itself is the thing that’s been taken, the attacker can produce signatures that pass. Your check confirms exactly what the attacker wants it to. The lock is still working; the key that opens it just isn’t yours anymore.

At that point the only real answer is to pull the anchor - revoke the compromised root, rotate to a clean one, and rebuild the chain beneath it. That is slow and painful, which is why it so rarely gets rehearsed before it’s needed.

Who is standing inside this

It is tempting to file this under a developer’s problem. It isn’t. You trust the app store to have signed the app on your phone. You trust the update that arrives overnight. You trusted the padlock in your browser this morning, which means you trusted a root certificate you have never seen, placed there by a decision you were never part of.

None of us checks all the way down. We can’t. Somewhere below the surface, every one of us is resting on an anchor we chose to trust on faith. The alternative is verifying the whole world ourselves, which is no life at all.

That is not a flaw to be fixed. Trust has to stop somewhere, and where it stops is where the value concentrates. The work is not to trust nothing. It is to know where your anchors are, keep them few, watch them closely, and be able to replace one fast when the day comes that you shouldn’t have.

03 · Lab · your turn

Trace the trust

Rehearse how a compromise at the trust anchor spreads to everything downstream, and which defenses actually contain it.

04 · Hope · carry this

The same trust that can be poisoned is what lets millions of strangers build on each other's work without ever meeting - and nearly all the time, it holds. Every attack that gets named and traced is the system learning where to watch, and choosing to keep the door open anyway.