The Bitcoin Core security policy now has a fast lane for bugs that are easy to find. Under a change merged on Thursday 22 October 2026 into the reference software for running a Bitcoin node, a vulnerability that the team flags as “easily discoverable” will be fixed in every maintained release at once, and its details will be published in an advisory alongside the fixed versions, with no embargo tied to its severity. The change came through pull request #1281 on the project’s website repository, opened on 16 October by Antoine Poinsot (darosior on GitHub) and merged by maintainer fanquake.
The new Bitcoin Core security policy page gives the test in one line: vulnerabilities “that can be discovered with minimal effort, such as through a simple LLM prompt”. If a language model could point an attacker at the bug, keeping it quiet for months buys little.
This is a change of process. It does not announce a vulnerability, an exploit or a flaw in Bitcoin’s cryptography, and it puts no coins at risk. Nothing changes for bitcoin holders today. For people who run a node, it changes how fixes will arrive.
What changed in the Bitcoin Core security policy
Poinsot explained the reasoning in an email to the bitcoin-dev mailing list on 22 October, the day of the merge. He wrote that the project is getting more reports of vulnerabilities that are easy to find or to rediscover, and he tied that to language models, which make some classes of bugs far cheaper to find and also make it easier to spot covert fixes, patches that went in without being labelled as security work. Disclosure, he argued, is always a trade-off: publishing details helps defenders keep pace with attackers, while waiting gives users time to upgrade.
According to the email, the approach until now leaned towards a long embargo because many node operators upgrade slowly. The side effect was that fixes often could not be backported to older versions and only shipped with the next major release. For bugs anyone can find, Poinsot called that “the wrong tradeoff”. His summary was blunt: “The embargo period achieves little but it delays the availability of a fixed release.”
The mechanism fits in a few lines. During triage, the team may flag a reported bug as easily discoverable. A flagged bug gets a fix backported to all maintained major versions, those point releases go out as soon as possible, and a security advisory with some details of the issue is published with them. The email gives the “simple prompt to an LLM” case as the kind of issue expected to qualify, and says the category is not limited to it.
The severity tiers stay as they were
Everything else in the policy still applies to bugs that are not flagged. Reports are sorted into four levels, and each level has its own disclosure delay. The current page sets them out as follows.
| Severity | What it covers (per the policy page) | When details are published |
|---|---|---|
| Low | Hard to exploit, or minor impact | 2 weeks after the release of the major version that contains the fix |
| Medium | Noticeably degrades performance or function, often needs non-default settings | 2 weeks after the last affected release reaches end of life |
| High | Significant impact on nodes or the network, typically remotely exploitable on a default setup | 2 weeks after the last affected release reaches end of life |
| Critical | Threatens the network itself: protocol-level coin theft, coins created outside the issuance schedule, a permanent network-wide chain split | Not covered by the standard policy; most likely an ad-hoc procedure |
| Any level, if flagged easily discoverable (new) | Can be found with minimal effort, such as a simple LLM prompt | With the fixed point releases, as soon as possible, no severity-based embargo |
For Medium and High bugs, waiting until the last affected release reaches end of life works out to roughly a year after the fixing major version ships. A pre-announcement, giving the number of fixed vulnerabilities and their severity, comes two weeks before embargoed details are released and is timed with a new major version. The page also notes that some reported issues may be serious yet need no embargo, and that some reports turn out not to be vulnerabilities at all.
The merged change itself is small. It adds two paragraphs to the page above the existing timelines, and alters one phrase: the pre-announcement now applies to “an embargoed vulnerability” rather than to any vulnerability. The lines setting the Low, Medium and High delays are untouched. A Japanese version of the page was updated on 23 October.
Why developers say secrecy is worth less when an AI can find the bug
An embargo makes sense when only the reporter and the maintainers know about a flaw. It makes much less sense when anyone with a chatbot and the public source code can find the same thing with little effort. That is the core of the argument Poinsot made in the pull request discussion between 16 and 22 October: quietly patching an easy bug achieves little, because “a trivial LLM scan” can surface it anyway, and backporting the fix to older branches would give it away.
The baseline, he said in the thread, remains to avoid drawing needless attention to security fixes, with more room to deviate from it. Fixes released this fast get less testing time in development branches, so he expects the team to accept a plainer patch that gives the bug away if it is safer, rather than a disguised one that could break something else.
The reviewers pushed on details rather than the idea. stickies-v asked for the text to be folded into the existing wording rather than bolted on at the end, which Poinsot did on 22 October. The same reviewer worried that attackers can now watch the repository cheaply, so a public fix pull request could alert many of them days or weeks before most users hear of it, and suggested disclosing no later than the moment that pull request opens. sedited doubted such early disclosure needed to be written into the policy, preferred deciding those cases ad hoc, and said marking fix pull requests as security fixes when they open would not help either.
ariard proposed a separate “Derogatory Process” section, an accelerated route in which an advisory might or might not be published with the fix. Poinsot called that “a bad idea”: an alert without details could push users who are not affected into a rushed upgrade. His example was a bug in block template creation, where miners should update at once while merchants can take a more careful path. For bugs serious enough to warn users before any fix exists, he pointed to the Critical level, which is already handled ad hoc. Four reviewers, stickies-v, instagibbs, murchandamus and fanquake, approved the final text, and fanquake merged it.
No replies were visible under Poinsot’s mailing-list post when Coindaro read it on 23 October.
A year of AI-found bugs in bitcoin software
The change follows a run of episodes in 2026 in which automated tools, often AI-assisted, turned up flaws faster than projects could triage them.
On 6 August, a volunteer group calling itself the Bitcoin Red Team reported 4,962 potential issues across 390 projects in its first 29.8 hours or so of work, according to Cointelegraph. About 720 were rated high or critical, and 21.4% had been reproduced at the time. The 16 volunteers, among them AnchorWatch chief executive Rob Hamilton and the developer known as Calle, combined AI tools with human review. Cointelegraph did not say whether Bitcoin Core’s own repositories were among the projects scanned.
Core Lightning had to deal with it directly. In August, Core Lightning said it was working through a large number of AI-generated vulnerability reports and shipped version 26.06.7. Version 26.06.8 followed on 22 September with fixes for crashes a sender could trigger, memory exhaustion through the REST interface and a channel-closing bug that could cost funds through a penalty. On 2 October, the team warned that nodes on 26.06.7 or earlier were being targeted and told operators to move to the latest release, Cointelegraph reported; some tests were deliberately held back.
Hardware wallets were part of the story too. The Coldcard thefts that began on 30 July, traced to a weak software random number generator in some devices, are now the subject of a proposed class action filed against Coinkite in Ontario. None of these cases was a bug in Bitcoin Core itself.
Which Bitcoin Core versions get the fixes
The backport promise only covers maintained versions. Bitcoin Core maintains the latest three major releases, according to its release lifecycle page, and versions past end of life generally get no security fixes. As of 23 October 2026, that means:
| Major version | First released | End of life |
|---|---|---|
| 31.x | 19 April 2026 | After v34.0 ships |
| 30.x | 10 October 2025 | After v33.0 ships |
| 29.x | 14 April 2025 | After v32.0 ships |
| 28.x | 2 October 2024 | Ended 19 April 2026 |
The project aims for a major release every six to seven months, and the release date of 32.0 has not been announced; the lifecycle page already lists 32.x as supported until 35.0 ships. When it ships, 29.x will drop out of support and out of the fast lane.
What node operators can do now
The project’s own pages give the practical steps. None of them is new, but the policy change makes them matter more, because an easy bug could now be public on the same day the fix is.
- Run a maintained major version (31.x, 30.x or 29.x), ideally the latest point release of the newest major you can use. Nodes on 28.x or older are past end of life and generally get no security fixes.
- Follow the project’s announcements and the security advisories page, so that an out-of-band point release does not go unnoticed.
- Download releases only from bitcoincore.org and check the signatures; the project says its binaries are built deterministically and signed.
- To upgrade, shut the node down fully and install the new version over the old one, as the release notes describe.
- Lightning operators running Core Lightning should be on the latest release (26.06.8 or later), following the team’s warning of 2 October.
The policy does not say how many bugs will be put in the new category. Each flagged bug means a point release for every maintained branch, so operators who wait for the next major version before upgrading will be the ones left exposed.
Embargoes, backports and point releases in plain words
Open-source projects usually handle security bugs through coordinated disclosure. The reporter tells the maintainers privately, the fix is prepared, and the details are held back (the embargo) until enough users have upgraded. The longer the embargo, the more nodes are patched before attackers learn what to look for.
A backport is the same fix applied to older branches that are still supported, so a user on 29.x does not have to jump to 31.x to be safe. A point release, such as 31.1, is a small update to an existing major version. Under the new rule, an easily discoverable bug produces a set of point releases on every maintained branch and an advisory explaining what was fixed. Our guide to where crypto hacks really happen explains why software bugs around a blockchain matter more in practice than attacks on the chain itself.
Open questions: who decides what counts as easy
The policy leaves the call to the team during triage, and neither the page nor the email defines “easily discoverable” beyond the LLM example. Several things were still unknown on 23 October:
- How the classification will be decided in borderline cases, and whether it can be challenged by the reporter.
- How many reported bugs have been put in the new category so far. No advisory has yet been published under the rule.
- Whether the Bitcoin Red Team’s August findings touched Bitcoin Core’s repositories.
- How reviewers’ concern about public fix pull requests alerting attackers will be handled in practice.
The next date to watch is the first advisory published under the new rule, and after that the 32.0 release, which will end support for 29.x. Elsewhere this week, the race between scanning and patching played out around two critical PHP flaws that attackers are probing, though no crypto platform has been shown to be hit.