AI-assisted scanning is surfacing thousands of potential bugs in Bitcoin-related open-source software, and some projects are already patching real issues.
- 501 projects scanned
- 7, 958 findings after 108 hours
- 1, 280 high or critical flags
- BTCPay Server already shipped fixes
Bitcoin Red Team says its AI-assisted review of Bitcoin-related open-source software now covers 501 projects and has produced 7, 958 findings after 108 hours of work. That is a serious signal, but not a clean bill of indictment. These are findings, not 7, 958 confirmed exploitable vulnerabilities.
That distinction matters. Some flags will prove real. Some will be duplicates. Some will be false positives. Others will need human context before anyone can say whether they’re a nuisance or a legitimate hole. AI can be useful here, but it also has a habit of vomiting out a mountain of noise alongside the useful stuff. Security teams call that triage. Developers call it a headache. Maintainers call it Tuesday.
The bigger point is harder to ignore: frontier models are now helping defenders scan large chunks of the Bitcoin software stack much faster than manual review alone would allow. That does not mean Bitcoin itself is broken. It does mean the surrounding ecosystem, wallets, Lightning tools, payment processors, authentication layers, and libraries, is getting stress-tested in public, at scale, and in a hurry.
Calle, a pseudonymous Bitcoin developer involved in the effort, said on Aug. 13 that the team had completed a basic scan of almost the entire Bitcoin open-source ecosystem. He added that much of the easier-to-find vulnerability surface had already been examined.
“massive collision”
“everything is broken, bitcoin is burning.”
Those are his words, and they are a characterization, not proof that Bitcoin Core or every Bitcoin project is compromised. Still, the sentiment captures the reality of scanning old code with new tooling: long-lived software, historical shortcuts, and odd authentication paths tend to age badly when a capable model starts poking around.
Bitcoin Red Team says 1, 280 of the latest findings were classified as high or critical. It also says 24.7% of findings had reproducible proofs and 29.4% were reported upstream to project maintainers. In plain English, some issues were serious, some could be demonstrated, and some had already been passed to the people who can actually fix them.
That is where the story stops being abstract. The clearest example is BTCPay Server, which credited Bitcoin Red Team Uncovers 85 Critical Flaws in 390 Open researchers Bruno Garcia and Ben Carman with reporting a critical vulnerability. Version 2.4.2 fixed a two-factor authentication bypass affecting Greenfield Basic Authentication.
For readers who do not spend their weekends reading auth code: Greenfield Basic Authentication is part of BTCPay’s login and access-control plumbing. A two-factor bypass there is not some trivia bug. It can turn a “secure enough” setup into a weak point very quickly, especially in systems handling payments and connected infrastructure.
BTCPay later confirmed that attackers had obtained LND admin macaroon credentials from affected installations and used them to access connected Lightning wallets. Macaroons are a form of high-privilege credential used by Lightning Network Daemon, or LND. If those get exposed, the damage can move from software bug to real money, real fast.
On Aug. 14, BTCPay announced another security-focused release candidate, v2.4.3-rc4, addressing vulnerabilities reported by those groups. That rapid follow-up is exactly how responsible disclosure is supposed to work: find the flaw, verify it, patch it, ship the fix, and hope the bad guys were a step behind. Ideally they stay behind. In practice, they usually try not to.
The earlier sweep from Bitcoin Red Team found 4, 962 potential issues across 390 Bitcoin projects, including 720 high or critical issues. The new tally is not directly comparable as a neat apples-to-apples snapshot. The project has expanded its coverage, so the bigger number reflects a broader pass rather than a simple rerun of the same test.
That matters because raw counts can be misleading if nobody explains what they measure. “Findings” are not the same as confirmed vulnerabilities, and “high or critical” does not mean every flagged item will survive human review. The precise numbers are useful, but only if they are handled with some discipline instead of turned into dramatic mush for social media engagement bait.
There is also a broader reason this is happening now. A Preliminary Assessment of Kimi K3's Cyber Capabilities by the U.K. AI Security Institute and CAISI, the U.S. AI security body, found that Kimi K3 outperformed GLM-5.2 on exploit-development testing, but still lagged behind the strongest U.S. closed models. In that assessment, Kimi K3 scored 32% on ExploitBench and reached arbitrary code execution on zero of 41 samples.
That is not the profile of a magical cyber superweapon. It is a capable model that can help with security work, but still has clear limits. Arbitrary code execution means an attacker can run code on a target system, which is serious stuff; the fact that Kimi K3 hit zero of 41 samples there is a useful reminder that benchmark hype and real-world offensive capability are not the same thing.
Still, the direction of travel is obvious. AI tools are making security research cheaper, faster, and more scalable. That helps defenders, until it also helps attackers, or until maintainers drown in noisy outputs they did not ask for and do not have the time to sort through. The real bottleneck is not just finding issues. It is validating them, prioritizing them, and patching them before someone else does.
OpenSats has already responded by creating a fast-tracked red-teaming grant route partly focused on reimbursing researchers for LLM costs. That is the kind of unglamorous but practical move the ecosystem needs. If advanced models are now part of serious defensive security work, then access and compute are not luxuries. They are infrastructure.
More than 40 Bitcoin and digital-asset organizations have also asked leading AI labs to give vetted open-source defenders controlled access to frontier models. That request says a lot about where the pressure is landing. If attackers can use the best tools while defenders get boxed out, the balance tilts in the wrong direction. Security should not be permissioned for the good guys and frictionless for the bad ones.
The main takeaway is not that Bitcoin is collapsing under a pile of bugs. It is that the software around Bitcoin is being examined more aggressively than before, and some of those inspections are uncovering real problems quickly enough to trigger patches.
That is healthy, even if it is messy. The noise is real. The false positives are real. The triage burden is real. So are the fixes, the disclosures, and the chance to harden a lot of code that probably should have been hardened years ago.
Key questions and takeaways
-
Does 7, 958 findings mean 7, 958 real vulnerabilities?
No. Bitcoin Red Team says the number includes potential issues flagged by AI, and many still need human verification before they can be treated as confirmed bugs. -
Is Bitcoin itself broken?
No evidence here supports that claim. The pressure is mainly on Bitcoin-related software around wallets, Lightning infrastructure, payment tools, authentication systems, and libraries. -
Why does BTCPay Server matter so much here?
It is the clearest proof that the scanning effort is producing real disclosures and patches, including a 2FA bypass and credential exposure tied to Lightning access. BTCPay Server Fixes Exploited LND Vulnerability in 2.4.2 and BTCPay Server warns active exploit could drain funds, urges show how fast this can go from bug report to active risk. -
How strong is Kimi K3 in cyber work?
A joint U.K. AI Security Institute and CAISI assessment found it outperformed GLM-5.2 on exploit-development testing, but it still lagged the strongest U.S. closed models. It scored 32% on ExploitBench and reached arbitrary code execution on 0 of 41 samples. -
What is the biggest risk going forward?
The main risk is triage pressure. AI can surface bugs faster than many maintainers can verify and patch them, while similar tools may also help attackers move quickly.
Bitcoin has always rewarded people who take security seriously instead of waving their hands and hoping for the best. AI just raised the tempo. The good news is that real flaws are getting exposed. The bad news is that the ecosystem now has to keep up without pretending the raw numbers are cleaner than they are.
Further reading
A few useful side doors on the security angle, the payout mechanics, and the wider red-team mindset.
