⚡ Key Takeaways

A firmware build error introduced into Coldcard hardware wallets in March 2021 silently weakened seed randomness for over five years, and attackers began draining affected wallets on July 30, 2026, with losses climbing past $100 million across multiple waves. Coinkite confirms frontier AI models it ran against its own code, including Kimi K3, all failed to catch the bug — but the viral claim that AI helped the attacker find or exploit it remains unconfirmed.

Bottom Line: Anyone holding a Coldcard-generated seed from March 2021 onward should update firmware and migrate funds to a newly generated seed immediately.

Read Full Analysis ↓

🧭 Decision Radar

Relevance for Algeria
Medium

Formal cryptocurrency use is restricted in Algeria, but informal Bitcoin and crypto holding is widespread, and hardware wallets like Coldcard, Ledger, and Trezor are commonly imported and used by individual holders and diaspora-linked traders. Anyone holding a Coldcard-generated seed from March 2021 onward is directly exposed regardless of geography.
Infrastructure Ready?
Partial

Algerian crypto holders typically self-custody without institutional security support, meaning firmware advisories like this one depend entirely on individual awareness rather than any regulated intermediary pushing the update.
Skills Available?
Limited

Verifying firmware versions, migrating seeds safely, and validating new wallet fingerprints require a level of technical care that is unevenly distributed among individual holders; community channels (forums, Telegram groups) are the likely — and imperfect — distribution path for this warning.
Action Timeline
Immediate

Anyone who generated a Coldcard seed between March 2021 and July 31, 2026 should update firmware and migrate funds to a freshly generated seed now; the vulnerability is public and actively being exploited.
Key Stakeholders
Individual Bitcoin holders and diaspora investors, crypto community moderators and educators, any Algerian fintech or exchange desk handling self-custody guidance

no formal regulator role given crypto’s restricted status in Algeria.
Decision Type
Tactical, with an educational layer

The immediate action is firmware/seed migration; the broader lesson — that AI code review is not a substitute for targeted security testing of build configurations — is relevant to any Algerian team building or auditing software, crypto-related or not.

Quick Take: If you or anyone you know holds Bitcoin on a Coldcard generated between March 2021 and July 31, 2026, treat that seed as compromised now: update firmware and move funds to a newly generated seed, testing with a small transaction first. Separately, resist the temptation to repeat the “AI found and exploited a five-year-old bug” story as fact — it’s an unverified theory, and the actually-confirmed AI angle (multiple frontier models, run by the vendor itself, failed to catch the bug) is the one worth taking seriously as a caution against over-trusting automated code review.

Advertisement

A Five-Year-Old Bug, Hiding in Plain Sight

On July 30, 2026, attackers began draining Bitcoin from hundreds of wallets generated on Coldcard hardware devices, made by Canadian manufacturer Coinkite. The first wave moved fast: roughly 1,083 to 1,196 BTC pulled from about 1,196 addresses in just 41 minutes (The Hacker News; an early sub-window put it at 594 BTC, or roughly $38 million, drained in 25 minutes (CoinDesk). It was not an isolated event — a second and third wave followed over the following days, including roughly 208 BTC from 1,912 additional addresses flagged early the following Sunday (CoinDesk).

The root cause traces back five years. Coldcard MK3 firmware version 4.0.1, released in March 2021, contained a build-configuration error: the code checked whether a macro existed rather than whether it was enabled, which caused the device’s hardware random-number generator check to silently fail. Instead of using true hardware entropy, affected devices fell back to MicroPython’s deterministic “Yasmarang” software pseudorandom generator when creating wallet seeds (The Hacker News). The practical effect was a collapse in usable entropy from a full 128 bits down to roughly 40 bits — weak enough to be brute-forced with dedicated computing hardware, no exotic tooling required (1023Jack).

Blockchain analytics firm Galaxy Research, whose running tally has been cited by multiple outlets tracking the incident, put losses at approximately 1,367 BTC (~$89 million) from 4,585 addresses across three waves as of August 2 (CoinDesk). By August 3-4, a fourth wave pushed the tally to roughly 1,816 BTC (~$116 million) across more than 5,200 addresses, according to blockchain forensics firm TRM Labs, which cited Galaxy Research’s figures (TRM Labs). TechCrunch later reported losses exceeding $130 million as tracing continued (TechCrunch). TRM Labs is explicit that the number is not final: funds are still moving, and the firm “has not computationally confirmed that every identified address was generated with weak Coldcard entropy.” Treat every figure in this story, including this article’s, as a preliminary snapshot of an incident still unfolding.

Coinkite released emergency firmware on July 31, 2026 — MK3 to version 4.2.0 and later, MK4/MK5 to 5.6.0 and later, and the Q model to 1.5.0Q and later. The company’s guidance is unambiguous: anyone who generated a Coldcard seed between March 2021 and the patch should treat that seed as compromised and migrate funds to a newly generated one, regardless of current firmware version. One mitigation did hold up: “A seed built with at least 50 fair, independent, private dice rolls is not at risk from this bug alone,” Coinkite said, since dice-roll entropy never depended on the flawed hardware RNG path (Bitcoin Magazine).

The Deeper Lesson: Coinkite Tested Frontier AI on Its Own Code — and It Missed the Bug

The more solidly sourced, and arguably more unsettling, part of this story is not about the attacker at all — it’s about the vendor’s own admission. In a blog post titled “Adding to the Public Record,” published August 4, 2026, Coinkite disclosed that it had run frontier AI models against its own firmware, both before and after the breach, specifically looking for exactly this class of defect — and none of the models caught it (Coinkite).

The company’s own words: “We’ve run AI-assisted review against our critical codebases, including in the weeks before the exploit. It did not catch this vulnerability.” Then, after the breach, they went further: “Since the incident, we’ve also tested our code against frontier models, including Kimi K3, Claude Fable, and Codex 5.6. None of them caught it.”

That is a striking admission on its own terms. Coinkite wasn’t testing AI code review in the abstract — it retested with full knowledge that a specific, now-public vulnerability existed in its codebase, using multiple leading models including the same Kimi K3 that would later be linked (unconfirmed, see below) to online speculation about the attack. All of them missed it. The failure mode was structural: the flawed macro check “looked correct” at a glance, and the models tested apparently did not probe the build-configuration and submodule boundary where the actual defect lived (Coinkite). Coinkite drew a pointed lesson from that: “It’s a reason for us, and anyone else relying on AI tools, to be specific about what they currently catch and what they might not.”

That is the confirmed, on-the-record AI angle in this story — not that AI found or exploited the bug, but that multiple frontier models, run by the vendor itself and pointed directly at the vulnerable code, failed to find it either.

Advertisement

Did AI Find the Bug for the Attacker? That Claim Is Not Confirmed

Within hours of the first drain, a different theory spread rapidly across crypto and security social media: that Moonshot AI’s newly released open-weight model, Kimi K3, had been used by the attacker to scan Coldcard’s long-public firmware source and surface the vulnerability. The timing fed the theory — Kimi K3’s weights were released July 27, 2026, just two to three days before the attacks began (1023Jack).

This attacker-side claim has not been substantiated by any named investigator, security firm, or Coinkite itself. As one detailed technical postmortem put it: “No investigator has named any actor,” and “the Kimi K3 attribution is an unverified community claim” (1023Jack). The same analysis undercuts the premise on technical grounds: the entropy collapse this bug caused (128 bits down to roughly 40) is well within reach of conventional brute-force computing. “A 40-bit search needs no LLM; specialised hardware brute-forces it.” No AI sophistication was strictly required to exploit the flaw once it was known, and no named source has confirmed which tools, human or automated, the attacker(s) actually used to find it in the first place.

It is also important to be precise about what Coinkite’s own blog post does and does not say. Its AI-related statements, quoted above, are entirely about Coinkite’s own defensive review of its own code — the company never claims an attacker used AI, never names an attacker, and never identifies the tool or method used to find or exploit the bug. Some secondary coverage has blurred this distinction: one outlet’s headline asserted AI was “likely involved in the hack,” while its own body text hedges considerably, citing unnamed “industry experts” who “believe AI was used” without offering direct evidence (Bitcoin Magazine). The same article quotes Coinkite co-founder NVK making a general observation about the technology category, not a claim about this specific incident: “AI-assisted code review can now find latent bugs at a speed that is outpacing even the industry’s most seasoned experts.” That is a statement about AI code review’s growing capability — not a confirmation that it happened here, and not a claim that an attacker used it.

In short: it is confirmed that AI failed to catch this bug when Coinkite pointed it at their own code. It is not confirmed, and should not be reported as fact, that AI found or was used to exploit the bug on the attacker’s side.

A Related but Separate Story: A Post-Breach Volunteer Audit

In the days after the Coldcard news broke, a volunteer group of Bitcoin developers — led by pseudonymous Cashu protocol developer “Calle,” alongside Rob Hamilton, CEO of Bitcoin insurance company AnchorWatch — began running Kimi K3 as a large-scale, OpenSats-funded security audit across roughly 400 Bitcoin-ecosystem projects, spending about $10,000 per day on compute. Within 24 hours the effort surfaced roughly 5,000 potential issues, including 85 rated critical and 635 rated high severity, most subsequently verified by the affected project owners (Forbes). This was a direct, industry-wide reaction to the Coldcard shock — developers scrambling to find the next hidden bug before an attacker does — not evidence of how the Coldcard bug itself was found. No source reviewed connects this audit effort to the original discovery of the Coldcard flaw.

No CVE identifier has been published for this vulnerability as of this writing; Coinkite issued its own advisory and firmware updates directly rather than through the standard CVE/NVD disclosure process.

What This Means Beyond Crypto Wallets

Two separate, both-true lessons run through this incident, and conflating them does a disservice to either. First: open-source code being publicly auditable for years is not a guarantee that subtle build-configuration bugs get caught — Coldcard’s firmware was open source throughout the five-year exposure window, and no human reviewer, automated scanner, or (per Coinkite’s own account) AI tool caught this particular defect until after it was actively exploited. Second: the appeal of “an AI found and weaponized a years-old bug within days of its release” is a compelling narrative precisely because it plays into real, justified anxiety about AI-accelerated vulnerability research — but compelling is not the same as confirmed, and treating a viral theory as established fact is exactly the kind of unforced error that erodes trust in security reporting.

Follow AlgeriaTech on LinkedIn for professional tech analysis Follow on LinkedIn
Follow @AlgeriaTechNews on X for daily tech insights Follow on X

Advertisement

Frequently Asked Questions

Was Kimi K3 actually used to find the Coldcard vulnerability?

This is not confirmed. It is a viral community theory that emerged because Kimi K3’s weights were released just two to three days before the exploit began. No investigator, security firm, or Coinkite itself has named an attacker or confirmed the tools used to find the bug. What is confirmed is a different, related fact: Coinkite tested Kimi K3 and other frontier AI models against its own code, both before and after the breach, and none of them caught the vulnerability.

How long was the vulnerable code publicly available before it was exploited?

The bug was introduced in Coldcard MK3 firmware version 4.0.1, released in March 2021, and remained in the codebase until Coinkite’s emergency patch on July 31, 2026 — a public exposure window of roughly five years and four months, independently confirmed by blockchain forensics firm TRM Labs and multiple security outlets.

How much money was actually lost, and is that number final?

Estimates grew over several days as more attack waves were identified: from roughly $38 million in the initial 25-minute sweep to approximately $89 million (per Galaxy Research, cited by CoinDesk) to around $116 million (per TRM Labs) and beyond $130 million (per TechCrunch) as tracing continued. TRM Labs has explicitly cautioned that its figures are not fully verified and that the total may still change as stolen funds move and additional victims are identified.

What should Coldcard owners do right now?

Coinkite advises updating to the patched firmware (MK3 to 4.2.0+, MK4/MK5 to 5.6.0+, Q to 1.5.0Q+) and, if your seed was generated between March 2021 and July 31, 2026, generating a brand-new seed on updated hardware and migrating funds — starting with a small test transaction. Seeds created using at least 50 independent private dice rolls for entropy are not affected by this specific bug.

Sources & Further Reading