In the second week of August 2026, a pseudonymous Bitcoin developer known as Calle posted a sentence that ricocheted around the industry: “Everything is broken, Bitcoin is burning.” Behind the hyperbole sat a dataset. The volunteer Bitcoin Red Team had just pushed Moonshot AI’s Kimi K3 — an open-weight Chinese frontier model released only two weeks earlier — through virtually the entire Bitcoin open-source ecosystem: wallets, Lightning applications, payment libraries, and the tooling around them. After roughly 108 hours of machine time across 501 projects, the team had logged 7,958 potential security findings, 1,280 of them classified high or critical.
That single campaign compresses everything this article is about: what AI models can now do to a codebase, who is pointing them at Bitcoin, what they are finding, and why a European regulation that begins to bite on 11 September 2026 turns all of it from an engineering story into a legal one.
The attackers got there first
Before the defenders industrialised, the attackers did. The open-source supply chain that Bitcoin and the wider digital-asset industry depends on has been under sustained, financially motivated assault for years — and the crypto ecosystem has consistently been the intended victim.
In September 2025, attackers phished the maintainer of chalk, debug, and sixteen other npm utilities — packages with billions of weekly downloads between them — and shipped a crypto-clipper that hooked browser APIs and silently swapped recipient addresses at the moment a wallet user approved a transaction, even selecting attacker addresses by visual similarity to evade detection. Weeks later the Shai-Hulud worm added self-propagation, turning isolated maintainer compromises into chain reactions. In March 2026, the Axios library — on the order of a hundred million weekly downloads — was backdoored for just under three hours through a hijacked maintainer account, in parallel with the TeamPCP campaign that compromised four widely used open-source projects in a single week. And in July 2026, attackers slipped a backdoor disguised as “telemetry” into the Injective blockchain SDK, wiring seed-phrase and private-key exfiltration directly into wallet key-derivation functions; automated publishing propagated it to eighteen packages within minutes.
The direction of travel is measurable. Sonatype’s 2026 State of the Software Supply Chain report counted more than 454,600 new malicious open-source packages in 2025 alone — a 75% year-over-year jump, pushing its cumulative blocked total past 1.2 million. And the tooling on the offensive side is evolving too: Google’s Threat Intelligence Group reported in 2026 that, for the first time, it had identified a threat actor wielding a zero-day exploit it believes was developed with AI, intended for a mass exploitation event.
Open-source repositories are being targeted precisely because they are the trust layer. Nobody needs to breach your infrastructure if they can poison a dependency you install voluntarily. And nowhere is that leverage higher than in software that touches keys and money.
The ColdCard debacle
Then, at the end of July, the abstract risk became a life-changing one. Beginning 30 July 2026, an attacker started emptying what was supposed to be Bitcoin’s safest hiding place: cold storage. In successive waves — the largest sweeping 1,082 BTC from 1,196 wallets in just 41 minutes, by Galaxy Research’s count — more than 1,800 BTC was drained from over 5,200 addresses generated on Coinkite’s ColdCard hardware wallets, with losses climbing past $116 million and, as later waves were attributed, estimated to approach $130 million. Nobody was phished. No device was stolen or even touched. Thousands of long-term holders who had done everything self-custody orthodoxy prescribes — hardware wallet, keys offline, air gap intact — watched life savings leave addresses they alone were supposed to control. The root cause was devastatingly mundane: a firmware build flag shipped in March 2021 caused affected devices to skip their dedicated hardware randomness chip and fall back on a weak software PRNG, collapsing effective entropy — to as little as roughly 40 bits on older Mk3 units — far enough that seed phrases could be reconstructed offline. Bitcoin’s mathematics held; the software wrapped around it did not. Coinkite shipped emergency firmware, destroyed vulnerable inventory, and pleaded with users to migrate — while conceding that no patch can repair a seed already generated on vulnerable firmware.
Then came the narrative war. Coinkite CEO Rodolfo Novak framed the exploit as “a sober reality of the new AI paradigm” — arguing that AI-assisted code review now surfaces latent bugs faster than even the most seasoned human experts, and that any firmware that is or has ever been public should be assumed to be under machine scrutiny by attackers and defenders alike. That claim is contested, and honesty requires saying so: no attacker has been identified, no proof has surfaced that a model found the flaw, and security specialists pushed back hard that a build flag disabling a hardware RNG is a human engineering failure that conventional review should have caught five years earlier. But in one sense the dispute is beside the point. Whether or not an AI found this bug, the ecosystem now knows that models demonstrably can find bugs of exactly this class at exactly this speed — and it responded as if the threat were real. Within days, the Boltz exchange paused operations to get ahead of AI-driven hacking attempts. And a volunteer counterforce assembled.
The rise of the red team in Bitcoin
The Bitcoin Red Team assembled within days of the ColdCard drain: an emergency, volunteer counterforce of sixteen researchers led by Calle alongside AnchorWatch CEO Rob Hamilton, backed by roughly $40,000 in AI compute and supported by OpenSats, whose new Code RED grant program now rewards responsible vulnerability disclosure across the ecosystem. The method pairs AI-driven analysis with human verification — models sweep wallets, Lightning implementations, and libraries; researchers reproduce and adjudicate; credible findings go privately to maintainers before anything is published.
The trajectory of its numbers tells the story of what AI does to vulnerability-discovery economics. The first sprint filed 4,962 findings across 390 projects in 27.5 hours — 85 critical and 635 high severity, averaging, by Calle’s arithmetic at launch, on the order of one critical exploit per researcher per hour. Days later, the expanded sweep stood at 7,958 findings across 501 projects. Calle’s summary: the basic scan of virtually the entire Bitcoin open-source ecosystem is complete, and the low-hanging fruit is done.
The findings come with texture that matters more than the totals. Vulnerabilities concentrated in older and lightly reviewed codebases. Lightning-related software — structurally complex, performance-sensitive, and hard to audit — carried disproportionate exposure. The prevalence of C-based implementations was flagged as a persistent structural risk. And how fast a project responded to a private disclosure turned out to be a diagnostic in itself: response speed, the team noted, is a visible proxy for project health. Unmaintained projects, they warned, should not be trusted.
The campaign has already produced verified, real-world impact. BTCPay Server — one of the most widely deployed self-hosted Bitcoin payment processors — shipped version 2.4.2 on 7 August patching a critical two-factor-authentication bypass credited in part to Bitcoin Red Team researchers, and subsequently confirmed the flaw had already been exploited in the wild to extract Lightning wallet credentials. That is the whole thesis in one incident: the vulnerability was real, it was being used, and machine-assisted review reached it before most humans would have.
It is worth saying directly what that took. Sixteen volunteers, roughly $40,000 of compute, a few weeks, and a discipline most funded security programmes never manage: private disclosure first, findings published only after maintainers had them, and their own reproduction rate stated in public rather than buried. They mapped an ecosystem that had gone unmapped for a decade and they gave the results away. Whatever else follows in this article, that is the reference standard for how this work should be conducted, and the Bitcoin ecosystem is safer this month than last because of it.
One constraint on that work deserves to be stated plainly, because it is routinely misread as a methodological choice. The team reported that usage restrictions on U.S. models for security research repeatedly blocked them — pushing them toward open-weight models like Kimi K3 and Z.ai’s GLM 5.2 that can be run locally without policy gatekeeping. Kimi K3 was not a compromise; on this work, at that moment, it was among the best instruments they were actually permitted to use.
That is a policy failure, not a research failure. Tool choice in security research is now shaped less by model quality than by who permits the work at all, and a team that reaches for the model that will actually run the job is behaving correctly. It should give Western labs pause: the defensive research happens either way. The only question is whose models it happens on — and whether the people doing it are forced into a narrower toolkit than the attackers face.
What 7,958 findings actually mean
Here honesty is owed — and the team was first to owe it. Of the 7,958 findings, 24.7% had been dynamically reproduced and 29.4% reported upstream at the latest tally, figures the team published itself rather than rounding away. A joint assessment by the UK AI Security Institute and U.S. CAISI found Kimi K3 capable but far from infallible — scoring 32% on exploit-development benchmarks, ahead of GLM-5.2 but well behind the strongest closed models, and achieving arbitrary code execution on none of 41 tested samples.
So this is not a list of 7,958 exploitable holes in Bitcoin, and nobody involved has claimed it is. Calle’s own framing was blunt about it: candidates are cheap, and if you cannot handle the resulting information overload, use AI to sort through it. That is the correct read, and it points at the real shift. AI has made candidate generation nearly free. What it has not made free is the judgment that separates a confirmed, reproducible, correctly scored vulnerability from a plausible-sounding hallucination — the same “AI slop” problem open-source maintainers from curl onwards have been drowning in.
The scarce resource in security has quietly moved from detection to adjudication. That is a property of the technology, not a shortcoming of anyone’s campaign — and a sweep that maps an entire ecosystem and a signed assessment of a single codebase are simply different jobs. The first tells you where to look. The second is what a regulator, an acquirer or an insurer will actually accept. Every serious actor in this space — attacker, defender, maintainer, regulator — is now downstream of that bottleneck.
Brussels sets the clock
Into this collision walks the EU Cyber Resilience Act, and its timing could hardly be sharper.
From 11 September 2026, Article 14 of the CRA obliges manufacturers of products with digital elements sold in the EU to report any actively exploited vulnerability they become aware of — within 24 hours for the early warning, 72 hours for the full notification, and 14 days for the final report — simultaneously to ENISA and their designated national CSIRT, via the single reporting platform. Critically, this applies to products already on the market, not just new releases. The regulation then applies in full from 11 December 2027, bringing with it binding secure-by-design requirements, the Annex I duty to apply effective and regular security testing, technical documentation containing the reports of those tests, and retention obligations stretching a decade. Fines under Article 64 reach €15 million or 2.5% of total worldwide annual turnover, whichever is higher.
Now put the two halves of this article together. AI-assisted campaigns are surfacing thousands of candidate vulnerabilities across open-source ecosystems in a matter of weeks — and some of them, like the BTCPay flaw, are being actively exploited, which is precisely the CRA’s reporting trigger. A manufacturer whose product embeds a compromised dependency, or a flaw an AI sweep surfaces and an attacker reaches first, is not facing a quiet engineering fix anymore. It is facing a 24-hour legal clock. And a manufacturer with no discovery process at all may breach Article 14 not by failing to report, but by never knowing there was something to report.
The uncomfortable corollary: much of the code now shipping inside those products is machine-written, and much of the review applied to it is performed by the same models that wrote it. Code written by a model and reviewed by the same model has been reviewed by nobody. Regulators, acquirers, insurers, and enterprise security teams are converging on the same question, and “our model checked its own output” is not an answer any of them accepts.
Refutation as a discipline: the CounterProof method
A sweep and an assessment answer different questions, and the second is where our own practice sits. CounterProof was not designed in a workshop as a product; it accreted while we secured our own threshold-cryptography payment infrastructure, where a defect that slips through doesn’t cost a customer relationship — it costs the operator its own funds.
The constraint that shaped it was the opposite of the Red Team’s. They needed breadth: 501 projects, fast, on whatever model would run the work. We needed a single finding to survive being wrong in public, on code holding our own money. Breadth forgives a false positive; a signed assessment does not. Different problem, different method — and we had the luxury of choosing instruments, which is precisely what the policy restrictions described above denied them.
CounterProof takes the adjudication bottleneck head-on, with a protocol shaped by the failure modes described above. Every assessment is a multi-lineage adversarial review: independent model families — not a second pass of the same one — attack each finding and try to refute it, with disagreements settled by reading the source, not by vote.
That last point is not a claim to better models. It is a claim about a measured property of all of them: a reviewer’s verdict is a sample, not a measurement. Give the same model the same bytes twice and it will not always return the same answer; give a question to several families and they fail in different directions, which is the only reason running several is worth the cost. We have watched a model confidently correct a regulatory citation and be wrong, while a model with no source access correctly declined to answer at all. The lesson is not that one lineage is superior. It is that a single lineage — any single lineage — cannot check itself. Nothing ships unrefuted. Every finding that survives is then either confirmed against the actual source — exact file and line, reproduction path, impact classification, with citations machine-resolved against the precise revision reviewed — or explicitly labelled plausible-only. Every finding names the evidence rung it actually reached — source trace, compile-proof, test, or live reproduction — and never implies a higher one. And every report carries a standing withdrawal contract: if a finding is shown wrong, it is retracted in writing.
In other words: where AI-era review generates noise at industrial scale, CounterProof’s output is deliberately the opposite of a triage queue. It is a signed, evidence-graded assessment under a persistent engagement identifier — structured to be handed to a diligence team, an insurer, or included in CRA technical documentation as an Annex VII(6)-shaped test report evidencing the testing duty. The independence is structural: we issue no assessment on code authored by CounterProof or by any company in our group, and our own codebase — much of it machine-written — runs through the same adversarial register continuously. We were our own first customer, and we remain our hardest one.
We will shortly be launching a new service on CounterProof.io, extending this practice to teams facing exactly the convergence this article describes: machine-written code, machine-speed adversaries, and a regulator’s clock. More on that soon.
Where this goes
Three predictions, held loosely.
First, the triage gap widens before it closes. Open-weight models will keep improving, sweeps like the Bitcoin Red Team’s will be repeated across other ecosystems, and the ratio of candidate findings to verified ones will get worse before adjudication tooling and disciplined methods catch up. Projects will increasingly be judged — by users, insurers, and acquirers alike — on their disclosure-response speed, exactly as Calle observed.
Second, the CRA becomes the forcing function that bug bounties never were. Voluntary disclosure norms produced patchy coverage for a decade; a 24-hour reporting obligation with turnover-scaled fines will do in eighteen months what goodwill did not, and the demand for regular, independent, documentation-grade security testing will restructure the audit market around evidence rather than badges.
Third, and most fundamentally for Bitcoin: an ecosystem whose security model rests on open review is about to discover whether machine review counts. The honest answer is that it counts only when an independent party is willing to verify the finding, grade the evidence, and sign. Detection has been automated. Accountability has not — and cannot be. That is where the value, and the responsibility, now lives.
CounterProof is an independent adversarial review practice of Clavestra Capital Limited (Malta). Proof attests; CounterProof refutes. counterproof.io
Sources: Coinkite security advisory and Forbes, Bloomberg, CBC, and Galaxy Research reporting on the ColdCard exploit (Jul–Aug 2026); Bitcoin Red Team disclosures via Bitcoin Magazine, Decrypt, crypto.news, Coinpaper, and Metaverse Post (Aug 2026); BTCPay Server 2.4.2 release notes; UK AISI / U.S. CAISI joint model assessment; Sonatype State of the Software Supply Chain 2026; Google Threat Intelligence Group, AI-enabled threat activity report (2026); StepSecurity analysis of the Injective SDK compromise (Jul 2026); npm supply-chain incident reporting (Sept 2025 – Mar 2026); Regulation (EU) 2024/2847 (Cyber Resilience Act), Arts. 13–14, 16, 69, Annexes I & VII.