Ledger's NPM account has been hacked

Original Article ↗ Hacker News Discussion ↗

Ledger’s JavaScript “Connect Kit” library on npm was compromised after a former employee’s npm account was phished, leading to malicious versions being published and used to drain an estimated $600,000 via injected wallet-draining code. Commenters criticize Ledger’s repeated security failures, reliance on CDNs and automated publishing that bypass strong 2FA, and the broader fragility of the JavaScript supply chain, while pointing to tools like LavaMoat, Socket, and Phylum, as well as stronger signing and hardware practices, as partial mitigations. The incident also reignites debate over the value of hardware wallets when users routinely blind-sign complex transactions and must still trust large centralized ecosystems around crypto.

Incident overview

  • Ledger’s NPM account for @ledgerhq/connect-kit was compromised via phishing of a former employee’s NPM credentials.
  • Malicious versions 1.1.5–1.1.7 were published; they injected a “drainer” that rerouted funds via a rogue WalletConnect project.
  • Ledger says the malicious file was live ~5 hours, with active draining for <2 hours, affecting ~$600k.
  • Version 1.1.8 was pushed as a clean replacement; NPM permissions were locked down and publishing secrets rotated.
  • The attack targeted dApps that dynamically loaded the kit via CDN; many downstream projects were implicitly exposed.

Ledger’s security reputation and hardware wallet model

  • Several commenters say Ledger has had “too many” incidents (data breach, controversial key-export-like features, phishing ecosystem), and have moved to alternatives (Coldcard, Trezor, SeedSigner, etc.).
  • Others argue the core security model still held: private keys on devices were not exfiltrated; users were tricked into signing draining transactions.
  • Debate over responsibility: some blame Ledger’s process and supply-chain choices; others blame users for blind-signing and not maintaining seed backups.

Blind signing and UX failures

  • Ethereum transactions are often complex and not human-readable on small hardware screens, leading to blind signing as the de facto norm.
  • Some say that until transactions are consistently rendered in clear text on-device, hardware wallets are “security theater.”
  • Other ecosystems (e.g., Cosmos) are cited as better at human-readable signing.

NPM, CI, and supply-chain security

  • Discussion that NPM “forces” or “optionally enforces” 2FA, but automation tokens and CI pipelines can bypass interactive 2FA.
  • Concern that a high-value package relied on phishable auth, ex-employee access, and automated publishing from GitHub Actions.
  • Debate over NPM’s responsibility: some call NPM negligent (weak signing, past integrity regressions); others say maintainers must configure security properly.
  • Long-running argument: traditional PGP-style maintainer signing vs newer centralized provenance systems; some strongly prefer decentralized PGP-style keys.

Detection tools and mitigations

  • Multiple security tools are mentioned (LavaMoat, Packj, Socket, Phylum, sandboxed installers) aimed at spotting malicious dependencies or obfuscation.
  • Some tools reportedly flagged this package; others admit gaps, especially when payloads are fetched from CDNs.

Centralization vs crypto ideals

  • Tether freezing the attacker’s USDT is seen as both useful (mitigating harm) and at odds with the original decentralization ethos.
  • Comments highlight that fiat-backed stablecoins (USDT, USDC) are centrally controlled and programmable (blacklists, freezes), unlike base assets like BTC/ETH.