In December 2023, malicious versions of Ledger's connect-kit JavaScript library were published and reached the sites that loaded it, where they were used to drain crypto assets. Would your organization have caught the same pattern? Check four things: who can publish your packages, what you pin, what loads at runtime, and how fast you can react.
What happened, in plain terms
On 14 December 2023, a malicious version of the library was reported, with Blockaid calling it a supply chain attack. Sites that used the library were exposed, because their front ends pulled the code in. Ledger said it identified and removed the malicious version and pushed a genuine one.
Reports on the cause differ, and this post does not pick a winner. As relayed by ForkLog, Ledger's account says a former employee was phished and the attacker reached that person's npm account. Ledger's account, as reported there, also says the attacker did not reach its code repositories or the dapps themselves. The Block's early report instead carried an allegation from Sushi's CTO that a CDN account was compromised. Ledger's incident report is the better source for its own cause, and early reports are worth treating as provisional.
The Hacker News listed versions 1.1.5, 1.1.6 and 1.1.7 as the bad releases. Reported losses moved as the investigation went on, from roughly half a million dollars in early reports to about 600,000 dollars in Ledger's later estimate. Treat the numbers as approximate.
This is not a story about careless people. A single stale permission is easy to miss in any company, which is why it makes a good test.
The checklist
Score one point for each item you can show, not just believe.
Publisher access
- Every package you publish has a named owner list that is reviewed when people leave.
- Publishing requires phishing resistant sign in, such as hardware keys, not only a password.
- Former employees and contractors have been removed from registry accounts, CDNs and package scopes. Ledger said it acknowledged an access lapse of this kind.
What you consume
- Production builds use a lockfile and install exact versions.
- New versions of a dependency are reviewed or delayed before they reach production.
- You know which of your dependencies are loaded in the browser from outside your control.
Runtime loading
- Front end scripts are bundled and served from your own origin where possible.
- Where you must load a third party script, you use subresource integrity so a changed file fails to load.
- A content security policy limits where scripts can come from and where data can be sent.
Detection and response
- You can list, within an hour, every site and app that uses a given package version.
- You can roll back or disable a front end quickly. In the reports, some affected apps disabled their front ends while the fix went out.
- Someone owns the first message to users, because users in this incident were being asked to sign transactions.
Wallet and signing flows, if you have them
- Ledger said its plan was to close blind signing in 2024. If your product asks users to approve actions, show them in human terms what they are approving.
Where Safeguard fits
An inventory makes the "which apps use this version" question quick. Safeguard builds an SBOM from your repositories and scans dependencies, including in CI and from the IDE, and the Gold registry and its free scan at gold.safeguard.sh/scan (100 dependencies) let you check a package list in the browser. Inventory does not stop a malicious publish, but it shortens the hour after the report.
What to do
- Audit registry, CDN and package scope owners this week and remove anyone who left.
- Require hardware key sign in for every publisher.
- Pin versions in production and add a short delay before adopting new releases.
- Move third party browser scripts to your own origin, or add integrity checks.
- Write the runbook: who finds affected apps, who ships the rollback, who tells users.
- Rehearse it once with a fake package version.
Quick check
Would a lockfile have protected a site that loaded the library from a CDN at runtime?
Not necessarily. A lockfile protects installs. A script loaded from a remote URL at runtime bypasses it, which is why integrity checks and self hosting matter.
Is a stale employee account a realistic risk?
Yes. Ledger acknowledged an access lapse in its own account, and offboarding checks for registry and CDN access are cheap to add.
Sources
- ForkLog: Ledger puts estimated user losses at about 600,000 dollars, searched 18 October 2026
- The Block: Security issue in Ledger ConnectKit library affects multiple decentralized applications, fetched 18 October 2026
- The Hacker News coverage of the Ledger supply chain breach, found by search 18 October 2026
Last reviewed: 18 October 2026.
