Bitcoin Core adopted a revised vulnerability disclosure policy on Thursday, October 22, 2026. The change follows a rise in reports of flaws that can be rediscovered quickly with large language models (LLMs). The project is shortening its embargo for these easy-to-find bugs, accepting less time for testing in exchange for faster fixes.
🔑 Key takeaways
- Flaws classified as “easily discoverable” will get a fix backported to every actively maintained major version, plus a security advisory.
- An AI-assisted audit campaign logged 4,962 findings, of which 85 were rated critical.
- A Coldcard firmware flaw, unrelated to AI, let attackers drain 594 BTC in 25 minutes, roughly $114 million.
- The main trade-off: fixes arrive sooner, but with less time in testing.
An AI-Assisted Audit Campaign
The revision grew out of a series of analyses run in late July 2026. A volunteer group of sixteen developers, the Bitcoin Red Team, ran AI models across roughly 390 projects in the Bitcoin ecosystem in a little over a day. The output was large: 4,962 findings, including 85 classified as critical.
Not all of those findings had been verified. According to FXStreet, only about one fifth had been reproduced at that stage. The available sources do not specify whether all 85 critical issues were confirmed. The distinction matters: it separates a warning signal from a list of genuinely exploitable bugs.
Incidents on the Ground
The campaign was followed by several incidents that made the issue concrete. The group privately reported a flaw in the BTCPay server, which was later exploited on production merchant servers. The attacks emptied Lightning nodes that merchants use to accept small bitcoin payments.
Core Lightning, one of the leading Lightning implementations, asked its operators to disconnect after AI-generated vulnerability reports sent to its small team proved accurate. The team had held the technical details back for two weeks.
| Incident | Date | Impact | Link to AI |
|---|---|---|---|
| BTCPay server | July 2026 | Merchant Lightning nodes drained | Flaw reported privately, then exploited |
| Coldcard firmware | July 30, 2026 | 594 BTC drained in 25 minutes, about $114M over four sweeps | None; the flaw did not need AI, though the vendor said AI helped uncover other bugs |
| Core Lightning | Not specified | Operators asked to disconnect | AI-generated reports, confirmed accurate |
Until now, Bitcoin Core applied an embargo period to give operators time to update their software before technical details became public. A fix could be deployed quietly, but the flaw itself only became visible once those details were published. The problem arose when patched versions could not be backported to older releases, forcing users to wait for the next major version, which typically arrives about every six months.
“The embargo period brings little benefit, but it delays the availability of a fixed version.”
Antoine Poinsot, developer, Bitcoin Core and Chaincode Labs
An “Easily Discoverable” Category and Four Severity Tiers
Antoine Poinsot proposed the revision after a rise in reports of flaws that are easy to rediscover. In his view, LLMs sharply reduce the difficulty of detecting certain classes of problems or spotting hidden fixes in code. The new policy therefore introduces a category called “easily discoverable”, covering flaws that can be found with minimal effort, such as a simple query to an LLM.
The test is based on how hard a flaw is to discover, not on which tool was used. A bug therefore falls into this category even if no AI has found it yet. When a vulnerability is placed there, Bitcoin Core must publish, for every actively maintained major version, a fixed release containing the patch as soon as possible, along with a security advisory. Fixes are thus backported to all active versions without waiting for the next major release. The advisory discloses some details, though not necessarily the full technical picture.
For all other flaws, the policy still relies on four severity classes, with timelines summarised below.
| Class | Scope | Examples cited | Disclosure timeline |
|---|---|---|---|
| Easily discoverable | Flaws findable with minimal effort | None classified at adoption | Fix and advisory as soon as possible |
| Critical | Theft of coins, issuance outside schedule, permanent network split | CVE-2018-17144 (denial of service and inflation) | Ad hoc procedure |
| High | Significant impact, often remotely exploitable | CVE-2024-35202, CVE-2024-52914, CVE-2019-25220 | Up to two weeks after end of life of the last affected version |
| Medium | Degraded performance, limited scope | CVE-2015-20111, CVE-2024-52921, CVE-2024-52922 | Up to two weeks after end of life of the last affected version |
| Low | Hard to exploit or limited impact | CVE-2024-52920, CVE-2024-52917 | Two weeks after a major version containing the fix |
The critical class covers threats to the fundamental security and integrity of the network. It falls outside the standard process, as it will likely require an ad hoc procedure. The high class targets flaws capable of causing widespread disruption, such as a remotely triggered crash or a node stalled for extended periods. The medium class groups flaws that significantly degrade performance, such as potential remote code execution on the local network when UPnP is enabled, or block propagation delays. The latter could leave a node waiting up to ten minutes before retrieving a block from another peer.
Low-severity flaws are hard to exploit or have limited impact. They may require non-standard configurations or originate from the local network. A malformed “getdata” message, for instance, can trigger a loop that consumes CPU without preventing the node from processing blocks.
Historical advisories show these issues are not new. The 30.0 release of October 10, 2025 fixed, among others, CVE-2025-46597, a very unlikely remote crash on 32-bit systems, and CVE-2025-54604 and CVE-2025-54605, which could fill disks through fake self-connections and invalid blocks respectively. Further fixes shipped in versions 29.0, 22.0, 0.21.0 and 0.20.0, as well as in older releases.
Trade-Offs and Community Reaction
The main trade-off identified by maintainers is shorter testing time. Fixes for easily discoverable flaws will have “less time to cook” before reaching users. Antoine Riard, a long-standing Bitcoin security researcher, wanted to keep the option of publishing a fix without an official advisory and deciding case by case what to withhold.
Poinsot rejected that option, stressing the risk of a rushed migration by users who would otherwise be unaffected. Alerting users to a security issue without any detail, he argued, could create unnecessary additional risk. Luke de Wolf, host of the Bitcoin Infinity Show and author of “Defending Bitcoin”, summed up a view shared by several observers.
“I have disagreed with Antoine’s approach to security in the past, but this is a good update.”
Luke de Wolf, host of the Bitcoin Infinity Show
No vulnerability had yet been placed in the new category at the time of adoption. The sources report no change in the bitcoin price and no other market reaction linked to the revision. The expected effect is therefore primarily operational, for node operators who will receive fixes and advisories faster, including when they are not yet running the latest major version.
Outlook: An Application Still to Be Measured
The first real application of the rule will show how Bitcoin Core sets the threshold for “easy discovery” in practice. That choice will define the policy’s real reach: a threshold that is too broad will increase the number of emergency releases, while one that is too strict will leave some flaws following the usual embargo path.
Three scenarios stand out. In the base case, rapid backporting shortens the exposure window for nodes that are slow to upgrade, without a sharp rise in incidents. In the adverse case, malicious actors exploit AI-found flaws before operators have applied patches, especially if advisories give too many clues. In the favourable case, the community adapts its testing and review tools to the faster rhythm, offsetting the reduced cooking time.
Sources
- Cryptoast: Bitcoin Core modifie sa politique de sécurité
- FXStreet: Bitcoin Core changes security policy as AI makes bugs easier to find
- Binance Square: Bitcoin Core security policy post
- Bitcoin Core: security advisories
- Crypto Briefing: Bitcoin Core AI bug disclosure policy
- CoinDesk: Bitcoin will now stop hiding bugs an AI can find in one prompt
Cet article est publié à titre informatif et éducatif. Il ne constitue en aucun cas un conseil en investissement. Faites vos propres recherches (DYOR) avant toute décision.
