preferred on
Points of Focus
- A 2021 firmware integration error in Coinkite’s Coldcard hardware wallets enabled offline key reconstruction.
- Confirmed losses are 1,596 BTC from roughly 7,300 addresses across several attack waves.
- Coinkite’s own AI-assisted code review missed the bug weeks earlier.
Over a thousand Bitcoin (BTC) have been moved into attacker-controlled addresses because of a five-year-old error in one of Bitcoin’s popular air-gapped hardware wallets. The device never left the owner’s possession. There were no phished seed phrases. No typical scam scenarios.
The private keys were simply recreated offline since the firmware was taking randomness from a deterministic software fallback rather than the hardware’s genuine random-number generator it was supposed to use.
What makes this story more pressing is that, weeks before the initial sweep, Coinkite ran one of the most powerful AI models available on the code and found nothing significant. Later, independent testers reported that, given the correct context, certain models could reveal the defective path in a matter of minutes. The discrepancy between such outcomes is the pressing question.
What happened with Coinkite’s Coldcard hardware wallets?
On July 30, 2026, the first big sweep began. Galaxy Research later identified 1,082.65 BTC transferred from 1,196 addresses in 41 minutes. According to early accounts, the initial catch was roughly 594 BTC from about 500 wallets in about 25 minutes. Once onchain clustering improved, the higher total became evident.
On July 31, a second wave grabbed another 76 BTC from over 1,400 addresses. The third wave was detected, resulting in approximately 208 BTC. By early August, Galaxy’s verified total had reached 1,596 BTC, which exceeds $100M, spread among around 7,300 addresses, three big waves, and 14 smaller clusters. A fourth alleged wave, which is now pending complete victim confirmation, would bring the total to around 2,055 BTC. The latest attack recorded as of August 11 happened on August 7, when an attacker moved 30 BTC worth about $1.94M to a new address. That’s roughly $130M.
🚨LOSSES FROM COLDCARD HACK EXCEED $100M
High confidence 1,596 BTC has been stolen from ~7300 addresses across 3 confirmed waves + more 14 smaller incidents.
If we add suspected (but unconfirmed), the total balloons to $130m (2k BTC).
More in the thread below 👇 pic.twitter.com/RAl3ib67qa
— Galaxy Research (@glxyresearch) August 3, 2026
Coinkite reported that at least 15 individual attackers have started exploiting the same vulnerability. According to Galaxy, around 90% of the stolen coins had not yet been relocated from their initial collecting addresses. On July 31, the manufacturer provided emergency firmware (Mk3 4.2.0+, Mk4/Mk5 5.6.0+, and Q 1.5.0Q+) and destroyed the remaining susceptible inventory.
Yet, updating firmware does not restore previously produced seeds. Impacted customers had to generate a new seed on repaired firmware (or another trusted device) and move funds.
Notably, owners who included at least 50 independent private dice rolls during seed creation or used a strong BIP-39 passphrase were unaffected.
Most users hadn’t.
COLDCARD Mk3 Security Advisory
If you generated a seed on a Mk3 after firmware 4.0.1, your funds may be at risk.
Mk4, Q and Mk5 are not affected based on our early analysis.
Read the advisory and migrate carefully:https://t.co/3vgPHOjMS7
— COLDCARD (@COLDCARDwallet) July 30, 2026
How the bug entered and stayed hidden for years
A firmware rewrite in March 2021 (versions starting around 4.0.0/4.0.1) is identified as the root of this problem. A configuration macro meant to activate the STM32 hardware RNG was set during the migration of elliptic-curve operations in such a way that a downstream library check merely confirmed the macro’s presence, not its value.
As a result, MicroPython’s Yasmarang software pseudorandom generator, which is a deterministic fallback never designed for cryptographic seed generation, was used in the build. The effective entropy on Mk2/Mk3 devices dropped to about 40 bits, mostly due to clock and serial number registers. About 72 bits were kept in later model versions (Mk4, Mk5, Q). The 128-bit target that renders brute-force search computationally impossible is well below both numbers.
Once an attacker had enumerated the reduced search space, they could obtain the appropriate private keys offline and sweep the related UTXOs without ever interacting with the actual device.
The flaw was found at the boundary between two sub-modules, not within the core cryptographic primitives, which are typically the subject of the majority of human and automated review. That issue placement explains why it withstood five years of open-source inspection, internal testing, and Coinkite’s AI pass just before the exploit.
Bobby Gray, founder of TEXITcoin and a cold-storage wallet builder, told AlphaWire:
“‘Cold’ describes where a wallet is kept… not whether its keys are secure. […] Air-gapping is irrelevant if the key was predictable from birth. A wallet that cannot prove how it creates randomness has no business safeguarding someone’s life savings.”
Why AI review produced opposite results
Coinkite has made clear declarations in public: “We have to assume that someone used AI to review previous versions of our firmware and stumbled upon this issue.” A few weeks prior, the company’s own test of a leading model “did not find this bug or anything serious.”
Following the disclosure, tests against several frontier models did not reveal it under the prompts and context windows that the company used.
According to community reports, certain models might discover the problematic RNG route in eight to twenty minutes after receiving the appropriate files and build flags. Those checks have not been independently replicated with complete disclosure of details such as prompts, model versions, and code snapshots, thus they cannot yet be considered as final.
Bitcoin Red Team update: we've grown to 16 globally distributed people working 24/7
We're running a large-scale ecosystem security audit across bitcoin code bases.
27.5 hours in, we've filed 4,962 findings across 390 projects. 85 critical and 635 high severity issues.
We're at… pic.twitter.com/iRCylprbY1
— calle 🟥 (@callebtc) August 5, 2026
What they do show is that AI performance on this type of defect is extremely dependent on context, prompt engineering, and whether the reviewer knows how to look for link-time symbol collisions or macro-value checks rather than pure cryptographic logic.
According to security specialists, a build setting that secretly disables a hardware RNG is essentially a human engineering mistake. A traditional assessment focused on the interaction points between libraries should have detected this failure years ago.
What’s the verdict? AI tools speed up the detection of hidden flaws when the correct questions are asked. Yet, they do not yet replace the necessity for such questions to be answered by humans who understand the threat model.
Gray, founder of TEXITcoin, framed the practical limit of AI-assisted review this way:
“A clean AI report is not a security certificate. If the model is only asked whether the code looks safe, it may simply provide a sophisticated version of “yes.” Teams must use multiple models, adversarial prompts and independent reviewers whose mandate is to find a way in… not confirm that the door appears locked. […] AI is useful as an attacker, not an approver. Security teams should never allow the same process that missed a flaw to certify that the flaw does not exist.”
Can AI reliably audit security-critical code?
Open-source firmware has both benefits and disadvantages because anyone can inspect it, including automated agents. Some language models are excellent at pattern matching across large codebases and can detect minor control-flow or configuration issues faster than most human teams.
Without specific direction, they struggle to validate runtime hardware execution, assess cross-object link-time behavior, and distinguish between intentional and accidental fallbacks.
According to security reports for 2026, AI coding tools continue to miss or create problems, especially at architectural boundaries rather than isolated cryptographic processes. The lesson here is not to forsake AI, but to approach it as one tool among many, and to thoroughly test interfaces for entropy, key content, and hardware abstraction.
How wallet manufacturers need to adapt
Hardware wallet makers (commercial in nature) are now under increasing pressure to improve design and production requirements. Seed-generation systems must strongly enforce hardware RNG at build time to avoid stealth software PRNG downgrades, which Coinkite has previously addressed with compile-time checks. Expect third-party audits to look beyond core cryptography and into module boundaries and configuration logic.
Relying on users to provide custom entropy, such as dice rolls or passphrases, is no longer an effective main protection. ‘Cold storage’ doesn’t automatically guarantee long-term security.
On the positive side, open-source transparency proved its value since the community quickly identified the bug, published migration guides, and pushed out firmware fixes within hours.
“Self-custody means taking responsibility for your keys, but users should not be expected to accept responsibility for defective engineering. They must protect their seed phrases, verify updates, and follow security guidance. They can also not be expected to audit firmware or test a manufacturer’s entropy claims. If a preventable defect in a wallet’s core security function directly causes losses, compensation and legal accountability should be on the table.”
What can regular crypto users still do?
Holders who are unable to genuinely manage complicated multi-sig systems have limited choices left. Gray proposed a smaller set of procedures and a larger warning against overreaction:
“Security that ordinary people cannot operate is not real security. Users should choose an open-source wallet with transparent seed generation, install firmware only through verified channels, keep the seed offline, use a strong passphrase stored separately, and test recovery before depositing serious funds. […] One defective self-custody tool does not invalidate self-custody. It proves that manufacturers must earn trust continuously rather than printing the word “secure” on a box.”
What to expect is that regular multi-model review may soon become a requirement for every project using cryptographic secrets.
Share
Most read articles
