> ## Content Index
> Fetch the complete content index at: https://bullquill.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Bitcoin Core fast-tracks fixes for bugs an LLM could easily find
- URL: https://bullquill.com/bitcoin-core-ai-bug-disclosure-policy/
- Published: 2026-10-25T04:15:18.000Z
- Updated: 2026-10-25T05:17:32.000Z
- Description: Bugs found "with minimal effort, such as through a simple LLM prompt" now get point releases for Bitcoin Core 29.x, 30.x and 31.x together with a security advisory. The trade-off is less testing time on development branches.
- Author: Rowan Ashby
- Tags: Crypto, Explainer, Bitcoin Core, Bitcoin, AI Security, #lang-en, #tr-bitcoin-core-ai-bug-disclosure-policy

## Key takeaways

- Bitcoin Core merged a change to its security disclosure policy on 22 October 2026 that creates a new "easily discoverable" class of vulnerability.
- Bugs in that class, described as flaws found "with minimal effort, such as through a simple LLM prompt", skip the usual embargo: fixes go out in point releases for every maintained version, together with a security advisory.
- Under the existing rules, medium- and high-severity bugs stay secret until two weeks after the last affected release reaches end of life, roughly a year after the fix first ships.
- The trade-off is less testing time on development branches before a fix reaches node operators, a cost the policy's author acknowledged.
- Operators on Bitcoin Core 29.x, 30.x or 31.x, the three maintained lines, are the ones who will receive these fast backported fixes.

The Bitcoin Core security disclosure policy fast-tracks fixes for vulnerabilities a language model could find. A change merged on 22 October tells the security team to backport such fixes to all maintained releases with an advisory, instead of waiting out embargoes of about a year.

The change rewrites part of the Bitcoin Core security disclosure policy, the document that sets out when the public learns about bugs in the software most Bitcoin nodes run. It does not touch the severity system for other bugs, and according to CoinDesk, no vulnerability had been flagged under the new rule at the time of its report.

## What changed in the Bitcoin Core security disclosure policy

The pull request, number 1281 in the bitcoin-core/bitcoincore.org repository, was opened on 16 October by Antoine Poinsot (GitHub handle darosior), a Bitcoin Core contributor who works at Chaincode Labs. It was merged on 22 October by maintainer Michael Ford (fanquake). The change adds about ten lines to the project's security advisories page.

The new text says the public disclosure timeline now depends on whether a reported vulnerability is classified as "easily discoverable" during triage. For those bugs, the policy says the project "will publish a point release containing the fix for each maintained major version as soon as possible, along with a security advisory, without applying the standard severity-dependent embargo periods." Everything else continues to follow the severity-based schedule.

Poinsot wrote in the pull request that the classification is expected to cover issues found with a simple LLM prompt but "is not restricted to those". In other words, any bug the security team judges trivial to find, by whatever method, can be fast-tracked.

### Old timelines vs the new fast track

The table below sets the existing severity tiers next to the new category, using the wording of the policy page on bitcoincore.org.

| Class                         | How the policy describes it                                                                  | When details are made public                                                                           | How the fix ships                                                     |
| ----------------------------- | -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------- |
| Low                           | Hard to exploit or minor impact                                                              | Two weeks after the major version containing the fix is released                                       | Usually in the next major release                                     |
| Medium                        | Noticeable degradation, limited scope or exploitability, often needing non-default settings  | Two weeks after the last affected release reaches end of life (about a year after the fix first ships) | Often only in the next major release                                  |
| High                          | Significant impact, typically remotely exploitable under default settings                    | Same as medium                                                                                         | Often only in the next major release                                  |
| Critical                      | Threatens the whole network, e.g. coin theft or unauthorised coin creation at protocol level | Handled ad hoc, outside the standard policy                                                            | Case by case                                                          |
| **Easily discoverable (new)** | Found with minimal effort, e.g. a simple LLM prompt                                          | Advisory published together with the fixed releases                                                    | Point release for every maintained major version, as soon as possible |

Source: Bitcoin Core security advisories page and pull request #1281 (merged 22 October 2026). The policy also keeps its pre-announcement step: two weeks before details of an embargoed bug are released, the project states how many fixed vulnerabilities and which severity levels are coming.

## Why Bitcoin Core made the change

The reasoning in the pull request is short. Poinsot wrote that the project had seen more reports of vulnerabilities that "can be easily (re-)discovered", which he put down largely to large language models lowering the effort needed to find certain classes of issues, or to spot fixes that were shipped quietly.

Embargoes exist to give users time to upgrade before attackers learn what to look for. But the old approach had a side effect: because a fix could not be backported without drawing attention to it, many security patches were held back and reached users only with the next major release. For bugs that anyone with a chatbot can find, Poinsot argued, that is the wrong trade-off. The embargo, he wrote, "achieves little but it delays the availability of a fixed release."

Covert fixing is also weaker than it used to be. According to Unchained and Decrypt, Poinsot argued that quietly patching such bugs would achieve little, since an LLM scan of the code could surface them and an aggressive backport would reveal them anyway.

### The wider wave of AI-found crypto bugs

The policy shift follows a busy few months for automated bug hunting in Bitcoin software. CoinDesk reported that a volunteer "Bitcoin Red Team" of 16 developers ran AI models across 390 Bitcoin projects in about a day in late July, logging 4,962 findings, 85 of them rated critical. Decrypt also described an AI-driven audit that logged nearly 5,000 findings across hundreds of crypto projects. Both outlets also said developers had patched AI-surfaced bugs in Lightning implementations and hardware wallets.

The same pressure is visible outside crypto. AI developers are now publishing cyber-capability scores for their models and, in some cases, deliberately reducing them, as Bullquill reported in its coverage of [Moonshot AI cutting the exploit score of Kimi K3.1 Pro](https://bullquill.com/moonshot-kimi-k3-1-pro-cyber-curbs/).

## The debate: what reviewers pushed back on

The change was not merged without discussion. Reviewers on GitHub raised several alternatives, according to the pull request thread and Unchained's account of it:

- **Disclose even earlier.** Stéphan Vuylsteke (stickies-v) argued that attackers can cheaply watch the repository and suggested disclosing such bugs no later than when the fix's pull request is opened. Poinsot replied that, for bugs below critical severity, warning users before a fixed version exists would likely do more harm than good.
- **Fix now, explain later.** Longtime Bitcoin security researcher Antoine Riard proposed keeping the option to ship a fix without an advisory and to decide case by case when to publish details. Poinsot rejected this, arguing that alerts without details could cause unnecessary risk, such as a rushed migration by users who would not otherwise be affected. The merged text does not include Riard's proposal.
- **Less bake time.** Poinsot acknowledged that fixes on the fast track will spend less time being tested on development branches before release.

## What node operators should watch for

For people who run a Bitcoin node, the practical effect is that some security fixes will now arrive as minor point releases, with an advisory explaining the bug, rather than months later inside a major upgrade. Bitcoin Core's lifecycle page says the project always maintains the latest three major versions.

| Version line | First released  | End of life |
| ------------ | --------------- | ----------- |
| 31.x         | 19 April 2026   | After v34.0 |
| 30.x         | 10 October 2025 | After v33.0 |
| 29.x         | 14 April 2025   | After v32.0 |

Source: bitcoincore.org lifecycle page, as of 25 October 2026.

Points worth checking, based on the policy text:

1. **Stay on a maintained line.** Fast backports go only to maintained major versions. Nodes on 28.x or older will not receive them.
2. **Follow the advisories page.** Easily discoverable bugs will be described at the same time as the fixed release, so the advisory and the release notes are the place to judge whether a node is affected.
3. **Expect smaller, more frequent point releases.** Because these fixes skip the long embargo, they may land outside the usual major-release rhythm.
4. **Verify downloads as usual.** A faster release cycle does not change the need to check release signatures and checksums before installing.
5. **Weigh the testing trade-off.** Fast-tracked fixes have had less time on development branches, so operators of critical infrastructure may want to watch release notes and developer channels for any follow-up fixes.

Operators who also hold coins on the same machine or in software wallets can review Bullquill's guide on [how to secure a crypto wallet seed phrase](https://bullquill.com/how-to-secure-crypto-wallet-seed-phrase/), since node software is only one part of a self-custody setup.

## What it means

The policy change is a small edit to one web page, but it marks a shift in how one of the most security-sensitive open-source projects thinks about secrecy. Bitcoin Core's disclosure rules were built on the idea that keeping a bug quiet buys users time. Poinsot's argument is that, once a cheap AI query can find the same bug, that time no longer exists, and the safer move is to get the fix into users' hands quickly and explain it openly.

The cost is real: fixes will be tested for a shorter period before release, and the Bitcoin Core team will give up obscurity more often. How often the new category is used, and whether fast-tracked point releases introduce regressions of their own, will only become clear once the first easily discoverable bug is triaged under the new rule. For more coverage of the project and the network, see Bullquill's [Bitcoin Core](https://bullquill.com/tag/bitcoin-core/) and [Bitcoin](https://bullquill.com/tag/bitcoin/) topic pages.

## Frequently asked questions

### What is an 'easily discoverable' vulnerability in Bitcoin Core?

It is a new classification added to Bitcoin Core's security policy on 22 October 2026 for bugs that can be found with minimal effort, such as through a simple LLM prompt. The security team decides during triage; the author of the change said the category is not limited to AI-found bugs.

### How long did Bitcoin Core previously keep security bugs secret?

Low-severity bugs are disclosed two weeks after the major release containing the fix. Medium- and high-severity bugs are disclosed two weeks after the last affected release reaches end of life, roughly a year after the fix first ships. Critical bugs are handled ad hoc.

### Which Bitcoin Core versions get the fast backported fixes?

Only maintained major versions. According to the bitcoincore.org lifecycle page, those are currently 31.x, 30.x and 29.x; nodes on 28.x or older will not receive the backports.

### What is the downside of the new Bitcoin Core disclosure policy?

Fixes on the fast track get less testing time on development branches before release, a trade-off acknowledged by the policy's author, Antoine Poinsot.

## Sources

- [GitHub: bitcoin-core/bitcoincore.org pull request #1281, "Update security policy for easy-to-find vulnerabilities"](https://github.com/bitcoin-core/bitcoincore.org/pull/1281?ref=bullquill.com)
- [GitHub: files changed in pull request #1281](https://github.com/bitcoin-core/bitcoincore.org/pull/1281/files?ref=bullquill.com)
- [Bitcoin Core: Security advisories and disclosure policy](https://bitcoincore.org/en/security-advisories/?ref=bullquill.com)
- [Bitcoin Core: Software life cycle](https://bitcoincore.org/en/lifecycle/?ref=bullquill.com)
- [CoinDesk: Bitcoin will now stop hiding bugs an AI can find in one prompt](https://www.coindesk.com/tech/2026/10/23/bitcoin-will-now-stop-hiding-bugs-an-ai-can-find-in-one-prompt?ref=bullquill.com)
- [Decrypt: Bitcoin Core rewrites its security policy for a world where AI finds bugs in one prompt](https://decrypt.co/381715/bitcoin-core-security-policy-ai-threats?ref=bullquill.com)
- [Unchained: Bitcoin Core rewrites security policy as LLMs make some bugs easy to rediscover](https://unchainedcrypto.com/bitcoin-core-rewrites-security-policy-as-llms-make-some-bugs-easy-to-rediscover/?ref=bullquill.com)

This article is for information only and is not investment advice.