PeckShield flagged it before anyone else did. $3.89 million, moving out of drained Ledger wallets into Binance deposit addresses. No firmware exploit disclosed. No Secure Element crack confirmed. Just funds leaving devices that were sold on the premise that this exact outcome could not happen.
I have spent enough hours inside signing flows to distrust the headline immediately. When a hardware wallet "drains," my first move is not to inspect the chip. It is to inspect the code that asks the chip to sign. The device, in almost every case, did exactly what it was told. The problem is who did the telling — and whether the user could read the instruction before approving it.
This is not a story about cryptography failing. It is a story about a trust chain that extends further than the marketing admits, and about a $3.89M figure that tells us less than the silence surrounding it.
Context
Ledger's security model rests on one claim: the private key never leaves the Secure Element. That claim is true. It is also radically incomplete, because a hardware wallet does not decide whether a transaction is safe. It decides whether to sign what the software hands it.
Trace the chain. A user opens a DeFi front end. That front end loads JavaScript. That JavaScript depends on npm packages. One of those packages — the integration layer between the dApp and the device — constructs the transaction payload. The device receives that payload, displays some approximation of it, and signs. The Secure Element held. Every cryptographic guarantee held. The money still left.
Ledger has been here before. In December 2023, the Connect Kit npm package was poisoned. A malicious version injected a drainer into every dApp that had integrated the library, and users who believed they were interacting with a legitimate interface were instead signing away token approvals. That event was reported in the low hundreds of thousands of dollars. This one is $3.89 million. Either the number is an aggregate across many victims, or it is a different incident entirely. The reporting does not resolve which, and I will not pretend it does.
Core
Here is the mechanical problem, and it is not a bug inside any single function. It is a category error baked into how the industry sells self-custody.
The hardware wallet's security boundary ends at "that one chip." The real attack surface extends to "the line of code the user downloaded." Between those two points sits the entire software distribution pipeline: firmware update channels, companion apps, browser extensions, npm dependencies. Every one of those is updatable. Updatable means writable. Writable means someone holds a publish key that can reach every user at once.
That is not a vulnerability. That is a privilege. And it is held by a small set of maintainers who are, statistically, far more likely to be phished than the chip is to be physically broken. The asymmetry is brutal: an attacker spends a weekend social-engineering a maintainer and reaches millions of devices. A defender needs SBOMs, reproducible builds, and multi-signature release pipelines — layered, audited, and maintained forever — just to hold the line. Defense is recurring cost. Offense is a one-time purchase.
The second mechanism is signature semantics. When the device shows you a transaction, it is not showing you the truth. It is showing you a rendering produced by the same software layer that may already be compromised. This is blind signing: you approve a payload whose meaning you cannot independently verify. The cryptography is intact. The human-readable layer is not. An attacker does not need to break AES. They need to make a malicious approval look boring — a "swap," a "claim," an innocuous allowance request that quietly grants unlimited spend.
I have watched this pattern since the ICO era. In 2017 I traced an integer overflow in a trading engine by isolating the exact function that misread its own bounds. The exploit was never in the primitives. It lived in the seam between what a system proves and what a user believes it proves. Hardware wallets prove key custody. They do not prove intent. Nobody selling them wants to say that out loud, because the entire pitch collapses the moment the boundary becomes visible.
Contrarian
Now the part the popular framing gets backwards. The narrative leans on "the difficulty of tracing stolen crypto across a decentralized network." That framing is obsolete, and the money itself disproves it.
The $3.89 million did not vanish into a privacy void. It flowed into Binance deposit addresses. Binance is a KYC chokepoint. Funds that cross that boundary stop being anonymous and start being account-linked. Tracing did not fail — tracing succeeded, and it succeeded precisely because the attacker routed through the one node where identity is mandatory.
The real difficulty is not on-chain. It is jurisdictional. It is whether a French company, a global exchange, and a security firm can coordinate a freeze fast enough to matter, and whether the attacker already converted to stablecoins and withdrew before anyone moved. The narrative says "hard to trace." The data says "easy to trace, hard to claw back." Those are different problems, and conflating them keeps users afraid of the wrong thing.
There is a darker implication. An attacker who knowingly sends stolen funds into a KYC exchange is either operating already-verified mule accounts or betting on conversion speed. Neither is a technical failure. Both are operational assumptions the attacker has priced in and accepted.
Takeaway
The chip was never breached. The trust chain was, somewhere upstream, in code most users will never read and cannot audit. The next incident is already being packaged — the attack economics are too favorable to stop. So the question is not whether your hardware wallet is safe. It is whether you can read what it is asking you to sign. Most people cannot. That is the real vulnerability, and no firmware update patches it.