Bitcoin Core
Bitcoin Core's New AI Bug Rule: Myth vs Reality
Bitcoin Core added a fast-track bug category after an AI scan found thousands of flaws. Here is what changed, what did not, and why it matters.
On October 22, 2026, Bitcoin Core's maintainers merged a change to the project's security policy, written by developer Antoine Poinsot, that changed part of how the software behind most Bitcoin nodes handles bug disclosure. The pressure behind it was specific: a surge of security reports produced with large language models, including a review of 390 Bitcoin-related projects that surfaced 4,962 potential flaws, 85 of them rated critical, spread across that wider set of codebases rather than sitting entirely inside Bitcoin Core itself. The resulting Bitcoin Core AI bug disclosure policy adds a new category, called "easily discoverable," for flaws simple enough that a single prompt to a language model can turn them up. On October 28, the first three bugs disclosed under it went public. Here is what the change actually does, checked against a few assumptions already circulating about it.
What the Bitcoin Core AI Bug Disclosure Actually Changed, In One Table
| Bug category | Disclosure timeline | Changed on October 22? |
|---|---|---|
| Easily discoverable (new) | Fix backported to every supported version, shipped in a point release as soon as possible, with a security advisory | Yes, this category is new |
| Low severity | Disclosed two weeks after the next major release | No |
| Medium or high severity | Embargoed until two weeks after the last affected version reaches end of life, roughly a year | No |
| Critical | Handled case by case, outside the standard timelines | No |
Only the top row moved. The other rows keep the timelines Bitcoin Core has used for years.
Myth: AI Found New Holes in Bitcoin / Reality: It Mostly Found What a Careful Reader Already Could
The 4,962-flaw figure sounds like a flood of fresh vulnerabilities inside the software that runs Bitcoin nodes. It is not, at least not that narrowly. That number comes from reviewing 390 separate Bitcoin-related projects, a category that spans wallets, libraries, and smaller tools well beyond Bitcoin Core, and it counts potential flaws, not confirmed ones. What is specific to Bitcoin Core is smaller and more concrete: three vulnerabilities, found by an automated scan that used a language model to read Core's code, each checked by a human contributor before it reached the project's security team.
The details of those three make the point better than any summary. One let any computer connected to a node running Windows, macOS, or BSD flood it with data until it ran out of memory and crashed. Another was reported from the scan on September 15, and six days later a different developer found the same flaw on their own. The third, rated low severity, turned up three times: once in the scan and in two separate reports from developers. These are real bugs. They are also the kind of flaw careful human reviewers were already finding; what changed is how cheaply a model could find them, not that they appeared out of nowhere.
Myth: Every Bug Now Gets Published Instantly / Reality: Only One Narrow Category Moved
It would be easy to read "Bitcoin Core drops its embargo" as a blanket policy shift. The table above shows why that is not what happened. Low-severity bugs still wait until two weeks after the next major release. Medium- and high-severity bugs still stay under embargo until two weeks after the last affected version reaches end of life, which works out to roughly a year, specifically so a flaw does not reach attackers before node operators have had a real chance to upgrade. Three more medium- and high-severity bugs, fixed in Bitcoin Core 30.0, are still on that slower track and are expected to be disclosed in about two weeks.
The only category that moved is the new "easily discoverable" one, built for exactly the problem a language model creates. The policy's own reasoning is that an embargo achieves little when anyone running the same prompt can find the same flaw just as fast; all it does is delay the fixed release.
Myth: A Node-Crashing Bug Puts Miners' Funds at Risk / Reality: Staying Online and Staying Honest Are Different Problems
The headline bug disclosed under the new rule is a denial-of-service issue, rated medium severity. It let an attacker crash an affected Windows, macOS, or BSD node by exhausting its memory. It was flagged on October 23, confirmed by developers the same day, fixed on October 27, and published on October 28. That is an availability problem, not a consensus or custody one. It does not rewrite blocks, does not touch a private key, and does not let anyone spend coins that are not theirs. A node that crashes needs a restart and a patch; it does not hand anyone else your funds.
That distinction is exactly why node reliability still matters on its own terms, independent of any single bug. A pool or a solo miner that depends on one node for everything is exposed to that node's own uptime, patched or not. NexusPool describes its own answer to that risk in how a found block reaches the network: the block is written to disk first, then submitted to three Bitcoin nodes from Los Angeles, Chicago, and Frankfurt, retrying until a node answers, while Singapore submits to its own separate node. NexusPool's core source is not public yet, so that description is our word, not something a reader can check in the code today. More on how that path works sits on NexusPool's technology page. None of it changes what a single Bitcoin Core bug can or cannot do; it means a block a miner found does not depend on any one node staying up through the submission.
Myth: Faster Disclosure Means Rushed, Unreviewed Code / Reality: The Tradeoff Is Stated in the Open
Poinsot's own proposal names the cost: fixes shipped on the fast track get less "bake time" in testing before they reach users. Not every developer agreed on how far to go, either. Antoine Riard, a longtime Bitcoin security researcher, argued for keeping the option to ship a fix without an advisory and hold the details back. That tradeoff is not hidden. It sits in the public record of the change, weighed against the alternative, which is leaving an easily found flaw unpatched for months while anyone with the same prompt can find it too. Treating that debate as settled in either direction would overstate what anyone currently knows about how the new category performs over time.
The Reality, In Short
Bitcoin Core narrowed one blind spot that language models exposed, kept its slower timelines everywhere else, and said so publicly, including the tradeoffs its own developers are still debating. That is a change to a disclosure calendar, not a reason to treat Bitcoin's node software as newly fragile or newly reckless.
This post does not claim that all 4,962 flaws found in the broader review sit inside Bitcoin Core itself, that the new policy makes any node immune to future bugs, or that NexusPool's own software goes through this same public disclosure process; NexusPool's core source is not currently public. Running a Bitcoin node, like running any software, carries risk a policy change does not remove, and nothing here is investment advice. Readers who want the full account should read CoinDesk's reporting on the policy change directly, and miners curious how NexusPool's own signed records work can check the Glass Ledger explanation or the current network status page.
Trust nothing. Verify what a policy change actually touches before assuming it touches everything.