Hardware Wallets: The Real Physical Attacks (and the One That Didn't Need to Touch Yours)

By the editorial team Bitcoinsurf · 22 October 2026

For years, the primary threat associated with hardware wallets bore a name borrowed from espionage: the "evil maid" — someone who exploits an unattended device — a hotel room, a repair service, a poorly verified secondhand purchase — to extract its secrets. It's a real scenario, documented, measurable. But it wasn't the one that caused the costliest hardware wallet hack of 2026.

According to a TRM Labs report published in 2026, approximately 1,816 BTC — roughly equivalent to $116 million at the time of the theft, a provisional count attributed to Galaxy Research and cited by TRM Labs, unverified independently — were drained from over 5,200 Coldcard addresses in four waves beginning July 30, 2026. No physical access to the device was necessary to trigger the theft. This contrast forces us to reclassify what we think we know about hardware attacks.

Key takeaways

• "Evil maid" attacks, side-channel attacks, and fault injection all require the device to be physically in the attacker's hands, often with specialized equipment like an oscilloscope.
• The 2026 Coldcard hack showed that a software flaw in seed generation can drain a wallet without any physical theft occurring.
• According to Ledger Donjon, using a general-purpose microcontroller as the main processor is a structural weakness, since side-channel attacks remain an architectural blind spot.
• Updating firmware protects future wallets, not those already generated with an active flaw.
• According to TRM Labs, self-custody shifts risk rather than eliminating it: firmware quality and entropy generation matter as much as physical possession of the device.

What is an "evil maid" attack on a hardware wallet?

The term describes a specific scenario: an attacker has access to the device for a limited time without the owner noticing, and uses it to extract secrets before returning it intact. Ledger Donjon, Ledger's security research team, has documented a real case on the Blockstream Jade, where an attacker with physical possession of the device can decrypt the firmware via a side-channel to inject malicious code.

The architecture at fault

The Jade is built around a revision of the ESP32 (for example the ESP32-D0WD-V3) as the main processor, paired with external flash memory housing the encrypted firmware. At startup, this firmware is decrypted using a key stored on the chip, through a process using AES-256, the encryption algorithm chosen by Espressif, the chip's manufacturer.

One detail tempers the severity of the scenario: the user's PIN is not stored on this external flash. The Jade's Blind PIN mechanism relies on Blockstream's server to limit login attempts and authorize or deny backup decryption, without the server knowing or verifying the PIN itself. What resides on the flash is the encrypted firmware and, depending on configuration, an encrypted seed backup — real plunder, but not the entirety of the secret protecting the funds.

This clarification changes nothing about the basic prerequisite: without the device physically in hand, this attack cannot be executed.

The side-channel: when simple power consumption reveals a key

A side-channel, or side-channel attack, exploits an indirect information leak rather than a flaw in the code logic. In the Jade's case, the method chosen by Ledger Donjon is correlation power analysis: measuring the chip's electrical consumption during decryption to statistically deduce the bits of the secret key.

According to Ledger Donjon, in the lab, the team recorded approximately two million power consumption traces to conduct this analysis. With only 300,000 traces, they managed to recover every byte of the key except one. On an actual Jade device, roughly 500,000 traces collected over two hours were sufficient to attack the key and then decrypt the firmware — a demonstration that the operation remains feasible within a short timeframe, not merely a theoretical lab curiosity.

The same principle has been verified elsewhere

A documented list of hardware wallet hacks maintained by thecharlatan.ch reports a similar case on Trezor: with physical access to the device and an oscilloscope, the private key could be extracted through power analysis, a result attributed to researcher Jochen Hoenicke. Two different manufacturers, two device generations, one common denominator: you need the device in hand, and dedicated measurement equipment.

Fault injection and reset: other attacks requiring physical possession

Fault injection involves deliberately disrupting a component's operation — through voltage or clock variation — to force it to skip a verification step or reveal sensitive data. In 2019, a fault injection attack targeting the ESP32-V1, the chip generation preceding the one used today in the Jade, was presented at Black Hat Europe. Espressif fixed the issue and recommended upgrading to the ESP32-V3, a hardened version of the component.

The timeline for side-channel discovery follows a standard disclosure pattern: the vulnerability was reported in October 2021, and Espressif published a security advisory in May 2022 announcing future mitigations.

On Trezor's side, thecharlatan.ch documents a third family of attacks also requiring physical possession: SRAM memory wasn't erased during a software restart, allowing its contents to be extracted via custom firmware and direct circuit board access — an attack known as platform reset.

All these attacks share one commonality: the device must be stolen, borrowed, or intercepted. The 2026 Coldcard flaw had no such requirement.

The counterexample that changes everything: Coldcard and the flaw that never needed your device

According to TRM Labs, a misconfigured build of Coldcard firmware 4.0.1, released in March 2021, caused seed generation to fall back on a weakened software pseudo-random number generator, drastically reducing the effective strength of the key compared to normal generation. No physical access to the Coldcard was necessary to exploit this flaw: the defect lay in how the seed was created, not in device manipulation.

Fast and automated exploitation

The first wave saw roughly 594 BTC move in 25 minutes from approximately 500 wallets to a single consolidation address — a pace betraying an automated script rather than manual intervention. TRM Labs ranks this incident as the third-largest hack of 2026 across all incident types, bringing the year's total to over $1.2 billion across 276 recorded incidents.

Laundering of stolen funds remained limited at this stage: a deposit of 64.9 BTC via Wasabi, a Bitcoin mixing service, and 200 ETH sent to Tornado Cash on August 4, 2026. A message inscribed on-chain via OP_RETURN even offered to launder funds for a 7% commission, evidence of opportunistic actors reacting quickly to such events.

Transaction construction differed across the four observed waves, suggesting multiple distinct attackers rather than one coordinated actor. TRM Labs makes no attribution to any specific group.

Table: which attacks truly require physical possession?

Assembling documented cases across the Jade, Trezor, and Coldcard, a dividing line emerges: some attacks only work if the device is physically intercepted, others bypass this requirement entirely.

The column deserving sustained attention is not that of physical access, but rather the origin of the firmware and the quality of key generation — two elements invisible to the user at purchase time.

What should you concretely do if such a flaw affects your device?

One important clarification before any checklist: updating firmware does not protect an already-existing wallet. If the seed was generated before the patch, the private keys derived from it remain compromised even once the device is fixed — the problem lies not in the code running today, but in the secret generated yesterday.

The recommended procedure, inspired by TRM Labs' detailed guidance, follows five steps:

1. Install the firmware update on the device, without relying on it to protect existing funds.
2. Generate a new seed on the now-updated device.
3. Verify the fingerprint of the new wallet and at least one receiving address before any transfer.
4. Send a small test transaction to the new address and await confirmation.
5. Migrate all funds once the test is validated, then confirm the old wallet is properly emptied.

Beyond this immediate response, TRM Labs emphasizes that a multisignature setup combining devices from different manufacturers and independent entropy sources offers genuine defense in depth — structural protection rather than merely reacting to an incident already occurred.

FAQ

Is an open-source hardware wallet more secure than a closed one? According to TRM Labs, open-source code and independent audits improve security but don't guarantee it. The Jade, with open code, nonetheless presented a side-channel flaw documented by Ledger Donjon — transparency helps detect and fix it faster, but it doesn't prevent its initial existence.

Why doesn't a firmware update secure an already-created wallet? The patch prevents generation of new weak keys but changes nothing about keys already derived while the flaw was active. This is why the recommended response doesn't stop at installing the update: it involves generating a new seed, verifying the fingerprint of the new wallet and a receiving address, then migrating all funds once a test is validated.

Was the 2026 Coldcard hack attributed to a specific group? No. The attempted money laundering observed — a deposit via Wasabi, passage through Tornado Cash, a 7% laundering offer published plainly on the blockchain — suggests an ecosystem of opportunistic actors operating in parallel rather than a single centralized operation.

Does a multisignature setup protect against a side-channel attack? Partially. If different keys in a multisig rest on the same device model, a side-channel method working on that model could, in theory, be repeated on each key. The multisig's benefit thus depends on actual diversity of devices and entropy sources used, not merely the number of required signatures.

Conclusion: the question is no longer "where is my device," but "who wrote its firmware"

Physical vigilance — never leaving your device unattended, checking its integrity after service repairs, distrusting secondhand purchases — remains a reasonable precaution. But neither the Jade flaw nor the Coldcard flaw resulted from user negligence. One required an oscilloscope and the stolen device in hand; the other required none of that. What these two cases share is that the risk lay in firmware design and entropy quality — elements the user can neither see nor audit themselves at purchase time.