Bitcoin Core drops the embargo: “the wrong tradeoff” on easy-to-find flaws

Bitcoin Core has changed the rules by which security vulnerabilities in the most important Bitcoin software become public. Anyone reporting a flaw that can be rediscovered with little effort no longer triggers months of silence, but a point release for every major version still under maintenance and a security advisory on the same day. The change was adopted into the disclosure policy on bitcoincore.org on October 22, 2026 at 16:06.

For you as a holder of Bitcoin this is no footnote from the developer world. The policy decides how quickly a fixed flaw in the software reaches you, and it decides how much of a head start an attacker has in the meantime. At around $81,400 per bitcoin on October 23, 2026, the value of entire wallets hangs on that question.

What Bitcoin Core changed in the policy on October 22

Bitcoin Core is the reference software of the Bitcoin network. It validates blocks, holds the blockchain and helps determine which transactions count as valid. Anyone running their own node is in most cases running exactly this software.

By its own account the policy distinguishes four classes of vulnerability. What has been added is not a fifth class but an attribute that cuts across them: at the initial assessment Bitcoin Core can classify a reported flaw as easily discoverable. Where this attribute is attached to a report, the previous waiting period falls away.

The process itself is documented transparently. The developer Antoine Poinsot submitted the change on October 16, 2026 as pull request 1281, under the title "Update security policy for easy-to-find vulnerabilities". After fifteen comments it was merged on October 22 by another Core maintainer. A single file was changed, with ten lines added and one removed. This is therefore no longer a proposal but the policy in force.

"Easily discoverable": the new attribute in the wording of the policy

Easily discoverable means, in the policy: a vulnerability that can be found with minimal effort, for instance through a simple prompt to a language model. That is the whole definition, and it is deliberately broad. The classification is expressly not limited to findings actually made with a language model; the simple prompt serves as a yardstick for the effort, not as a prescription for the tool.

Where a report carries this attribute, the policy states: Bitcoin Core issues a point release with the fix for every maintained major version as quickly as possible, together with a security advisory, and does not apply the otherwise usual embargo periods that depend on severity. A pre-announcement two weeks before the details are published still exists, but only for flaws that are actually under embargo.

A year of embargo against a point release on the same day

To understand how large this difference is, it is worth looking at the deadlines that continue to apply alongside it. For flaws without the new attribute everything stays as it was.

A vulnerability of low severity is disclosed two weeks after the release of a major version that contains the fix. At medium and high severity, disclosure comes only two weeks after the last affected version has reached the end of its maintenance. The policy puts a figure on this point itself: roughly a year after a major version with the fix first appeared.

From this follows the real harshness of the old rule, and the policy names it openly. Because Bitcoin Core relies on a long embargo, security fixes can as a rule not be backported into older versions. They reach users only with the next major version. Anyone sitting on a maintained but not the latest major version therefore sometimes did not receive a fix for months.

Antoine Poinsot calls the embargo on easy findings the wrong tradeoff

Poinsot justifies the step with a weighing that is part of every security policy. Transparency and time to update pull in different directions: openness puts attackers and defenders on an equal footing, but can make a flaw public before users have updated. Because of the nature of the project and a slow updating culture, he says, Bitcoin Core opted for the longer embargo.

For easy-to-find flaws that weighing no longer holds. Poinsot writes literally that this is "the wrong tradeoff", and adds: "The embargo period achieves little but it delays the availability of a fixed release." As the occasion he names a rise in reports of flaws that can easily be rediscovered, and traces this to language models markedly lowering the bar for finding certain classes of error or for recognising hidden fixes.

The second part of that sentence is the more uncomfortable one. A quietly inserted fix in open source code used to be hard to recognise as such. If that can be traced automatically, the embargo gives away the flaw it is trying to hide.

LLMs lower the bar, and the red team run shows it in figures

How far the situation has shifted is shown by a run that CoinDesk reported on October 23, 2026. A volunteer group called Bitcoin Red Team, sixteen developers according to that report, had AI models run over 390 Bitcoin projects at the end of July 2026, in about a day as the report describes it. 4,962 findings were logged, 85 of them classified as critical.

These figures are raw findings and not confirmed vulnerabilities, and the reports on the run differ from one another; one account puts only around a fifth of the findings as confirmed. As an order of magnitude the point stands all the same: what used to cost a specialist weeks of manual work now runs overnight and across the board.

That damage arises from it is documented in the same report. A vulnerability in BTCPay Server, which the group had previously reported confidentially, was according to the report exploited within days on live merchant servers and drained Lightning nodes. Core Lightning called on its operators in August 2026 to sever connections, after AI-generated reports to the small team had proved genuine. Review by humans remains necessary in this, because some of the machine-generated reports in the end describe no vulnerability at all.

That a flaw does not have to be found by a language model to become expensive is shown by a case from the same summer. In the firmware of the Coldcard hardware wallet an error had lain dormant since 2021 according to the report, through which 594 bitcoin were withdrawn in 25 minutes on July 30; across four withdrawals the loss added up to almost $114 million. Anyone wanting to compare the models of different providers and their update paths will find the overview in the hardware wallet comparison.

Three major versions count as maintained: 29.x, 30.x and 31.x

"Every maintained major version" is the decisive half-sentence of the new rule, because it tells you whether a point release reaches you at all. Bitcoin Core keeps to a terse commitment here: the last three major versions are always maintained, as stated in the project's lifecycle plan on bitcoincore.org.

At present that is three releases. Version 31.x appeared on April 19, 2026 and is the current edition. Version 30.x dates from October 10, 2025, version 29.x from April 14, 2025. The end of maintenance is tied in each case to the coming major versions and not to a fixed date. Version 28.x dropped out of maintenance on April 19, 2026 and therefore also receives no point release under the new rule.

How to check which Core version your own node is running

If you run your own node, the version number is the only detail that decides your situation. It appears in the Bitcoin Core interface under the menu item for program information, and on the command line the call bitcoin-cli -version delivers it. If the first number is below 29, you are outside maintenance, and none of the fixes described here will reach you.

Two further points are now more important than before. First, it is worth following the project's security advisories, because advisory and fixed version will in future appear on the same day and the lead time is missing. Second, the reaction time has become shorter to your disadvantage: with publication the details are public, and anyone who does not update carries on with a known flaw. The same principle applies to the software wallet on your computer or phone, whose update paths stand side by side in the software wallet comparison.

For holders without their own node the responsibility shifts

The large majority of investors in Germany do not run their own node. For them the change takes effect indirectly, namely through the services that run Bitcoin Core in the background. These include exchanges, custodians, payment service providers and the servers behind some wallet apps.

There the new rule is first of all good news. An operator who previously had to wait for a major version now receives the fix as a point release for the version they are running anyway. That lowers the barrier to updating at all. At the same time the pressure to do it quickly rises, because the details of the flaw become public at the same moment.

Hardware wallets and exchanges hang on the same disclosure

One qualification belongs here so that the reach of this change is not overestimated. It concerns Bitcoin Core, not the entire Bitcoin toolkit. Hardware wallets, wallet apps, payment servers and Lightning implementations each have their own policies, and the cases from this summer come for the greater part from exactly those projects. The question of how promptly a provider follows up with firmware and app remains a question for the provider.

For you that means: the decision whether you self-custody or have others custody merely shifts who takes on the updating. It does not take the task away. Anyone who self-custodies carries the version maintenance for node and wallet. Anyone whose holdings sit with a custodian relies on that firm's technology installing the point releases promptly, and trades control for responsibility.

A further point is still open. Up to October 23, 2026 no flaw had been classified under the new rule, according to the CoinDesk report. How short "as quickly as possible" turns out in practice will only show at the first real case. Poinsot too concedes that such fixes have less time to mature before they reach users. A proposal to drop the security advisory entirely he rejected, by contrast: informing users of a flaw without naming details could create unnecessary additional risk.

Bitcoin Core: point release and advisory arrive on the same day

1. Establish the version number. With your own node, check whether the first number reads 29, 30 or 31. If it is below that, update to a maintained release. For the wallet side, the software wallet comparison helps with the question of how the provider delivers its updates.
2. Follow up on the hardware wallet firmware. The Coldcard flaw lay in the firmware for four years according to the report. Check when you last updated, and how your model receives updates at all; the hardware wallet comparison places the providers side by side.
3. Clarify responsibility. Decide who takes on the updating in your case. If part of your holdings sits with a custodian, check its statements on technology; an assessment of the providers is in the exchange comparison.

(As of October 23, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)