how it happened
- whoattackersphished a former employee
- the gappackage registryex-employee access never removed
- thenapps using the libraryserved it automatically
- the result~5 hours livewallets drained
what everyone assumed
Modern front ends are assembled from many small parts, and each one feels too minor to be a threat. A wallet connector is a convenience widget. The reasonable belief is that the danger lives in the contracts and the keys, not in a helper library that just brokers a connection, so when the package updates, you ship the update, because that is what keeping current means.
what happened
The quiet stretch here was measured in hours rather than months, which is its own lesson about how fast a shared dependency moves. A former Ledger employee was targeted by a phishing campaign that gave attackers access to that person’s account on the npm package registry. Using that access, the attackers published malicious versions of the Connect Kit, numbered 1.1.5, 1.1.6, and 1.1.7, carrying a wallet-draining payload. Because the affected applications pulled the library from the registry, they served the poisoned code to their own users automatically, without changing anything on their own side. The teams running those applications had made no mistake that day. They had simply embedded a library and let it update.
step by step
- a former employee is phishedThe attacker gets their npm account.
- malicious versions 1.1.5 to 1.1.7 are publishedWith a wallet-draining payload.
- apps pull the library automaticallyDownstream sites serve the poisoned code without changing anything.the assumption breaks here
- 1.1.8 replaces it after about five hoursAround 600,000 US dollars drained.
how it surfaced
Ledger identified the compromise and replaced the malicious package with a clean version, 1.1.8, ending the exposure after roughly five hours. Reporting placed the amount drained at around 600,000 US dollars, with some estimates higher, taken from users of downstream applications who had never heard of the library at the center of it. The realization arrived in the ratio: a few kilobytes of borrowed code, loaded by dozens of sites, turned every one of them into a delivery channel for the same theft.
A dependency you embed runs with your users’ trust, not its own.
However small the library, whatever it can reach, it can reach through you, which makes its supply chain part of yours.
picture it at a company like yours
The company here is made up. The other two paths are not: they happened, and each links to the story.
- in this storythe day it mattersThe library's publisher is hacked and a malicious version goes out.what it costs youYour site serves the attack to your own customers for hours, without you changing a thing.
- or it goes like thisit happenedSolarWinds / Sunburst, 2020howA genuine, signed update from a certified vendor carries a backdoor.what leavesa quiet way into your networkwho ends up with ita state intelligence service
- or it goes like thisit happenedtj-actions/changed-files, 2025howA build helper everyone uses is hijacked and its versions repointed.what leavessecret keys, printed into build logswho ends up with itanyone reading public logs
sources
your turn
what you can do about it
this week
List the third-party scripts and packages that run in front of your users, find which ones auto-update versus which are pinned, and ask who would notice, and how fast, if one of them started behaving differently.
Your application loads code you did not write, from registries you do not control, and some of it updates on its own. That convenience is the assumption.
go deeper
if you're not sure where to start
Run the offboarding checklist on one leaver. It covers every account and token to close when someone leaves.
open the checklist →