The 2025–2026 supply-chain attacks share one trait: they fire at install time
From the chalk/debug compromise to Shai-Hulud, Axios and LiteLLM — the recent npm and PyPI attacks that activated during installation, and why lockfiles and provenance didn't stop them.
Modern software is assembled, not written. Every build pulls in code from maintainers you'll never meet — and over the last two years a run of high-profile compromises has turned that trust into an attack surface. The striking part isn't that malicious packages exist. It's when the malice runs: during npm install or pip install, or the moment a module is imported — not in the tidy source you'd skim on a repository page.
The cases
- chalk & debug (September 2025). A maintainer account was compromised and trojanized versions were published for packages that together see on the order of two billion weekly downloads. The trust violated wasn't one library's — it was an entire web of dependency trees.
- Shai-Hulud (September and November 2025). A self-propagating worm stole secrets, reused stolen tokens to publish further, and spread across hundreds of packages and thousands of repositories. Later waves added outright destructive behavior.
- Axios (2026). A hidden dependency existed only to run a postinstall step that fetched a cross-platform remote-access trojan — then tried to erase its own traces to frustrate forensics.
- LiteLLM on PyPI (2026). A compromised release shipped an infostealer that went after SSH keys, cloud tokens, Kubernetes secrets and
.envfiles — proof the risk isn't confined to npm, and that AI tooling is squarely in scope. - TanStack (2026). A compromise with impact disclosed by a major AI company: limited credential exposure and isolated devices. No user-data breach, but a very real containment scramble — the enterprise blast radius made concrete.
Why the usual defenses didn't catch them
These weren't fringe typosquats. They were trusted names, hit through compromised accounts and spurious releases — exactly what defeats the standard playbook:
- Lockfiles pin versions, not behavior — a pinned version can still be malicious.
- Provenance and reputation assume the publisher is honest; a hijacked account produces perfectly valid releases.
- Source review and CVE lists describe what code looks like, or what was bad yesterday — not what a package does the first time it runs.
The question has shifted from “where did this come from?” to “what does it do when it runs?”
That shift is the whole reason depgaze exists: it judges a dependency by its behavior at install time, in plain language, before it reaches your machine.