AI-Driven Code Review Likely Exposed Coldcard Seed Weakness, $38M in BTC Drained

A subtle build mistake inside Coldcard’s open-source firmware appears to have turned a hardware-strength seed into a softer target—and an attacker likely used AI to find it. Roughly 594 BTC, about $38 million, moved out of around 500 wallets in a 25-minute window, with 562 BTC later consolidated into a single address. Firmware hotfixes are out, but any seed created on affected versions remains weak and must be replaced.

The uncomfortable edge: Coinkite says a likely AI-assisted trawl of historical firmware changes uncovered the issue, while an internal AI scan weeks earlier found nothing conclusive. Offense and defense are increasingly using the same models; speed and specificity often decide who wins.

What actually failed - Two functions with identical signatures provided randomness: a hardware generator written by Coinkite and a software fallback from MicroPython. - A preprocessor check verified only that a setting existed, not its value, so the build linked against the software fallback without throwing errors. - Seed generation had been unknowingly relying on the fallback since a March 2021 migration.

Who’s affected—and by how much - Coinkite’s initial post flagged Mk3 seeds created after firmware 4.0.1 as at risk. - Subsequent analysis says every current model is affected to some degree. - Mk3: effective search space near 40 bits vs the intended 128. - Mk4, Q, Mk5: secure elements add entropy, lifting them to roughly 72 bits—better, but not the target. - Tapsigner, Opendime, and Satscard rely on different code paths and are not impacted.

Important nuance: A seed made on an affected Coldcard stays weak even if you restore it onto another brand’s device. Trezor told users their own wallets are safe. Block published an independent readout and said none of its products are affected; its hardware lead urged anyone exposed to move promptly and carefully.

What users should do now - Update to the emergency firmware: 5.6.0 for Mk4/Mk5 and 1.5.0Q for Q. Updates do not strengthen seeds already created. - Generate a new seed on patched hardware and migrate funds. Consider adding a strong BIP-39 passphrase, at least 99 dice rolls, or both. - Mk3, now out of support, has a separate migration path provided by Coinkite.

The single issue that matters: entropy you can prove Hardware wallets live or die on randomness. Open-source transparency is a strength, but it invites code archaeology—especially when models can diff versions, spot duplicate interfaces, and reason about compile-time flags at machine speed. General-purpose AI audits often miss domain-specific traps; attackers specialize.

Teams should treat entropy like a regulated component: - Make compile-time guards test values, not just definitions, and enforce this with custom linters that fail builds on duplicate cryptographic interfaces. - Add continuous, versioned health tests for randomness sources, including min-entropy estimates and fail-closed behavior when a hardware RNG isn’t present. - Require independent, reproducible builds with targeted rules that flag any path that routes seed generation through software fallbacks. - Incentivize third-party red teams to perform “AI-first” audits across historical commits and configuration states, not just current HEAD.

On the communication front, early statements often underweight edge cases. Initial messaging suggested Mk4, Q, and Mk5 weren’t affected; later notes clarified partial impact with improved, but subpar, entropy. In high-stakes key material, even “somewhat better” can lull users; precision and migration playbooks matter more than reassurance.

This episode won’t be the last where machine-scale review tips the balance. Wallet makers that pair formal randomness guarantees with model-aware static analysis will likely reduce their attack surface. Users can add resilience, too: passphrases and real-world entropy (dice) provide a hedge when firmware falls short. Move funds methodically, verify on patched hardware, and assume seed material created on vulnerable versions is permanently compromised.