Bitcoin Core Speeds Vulnerability Disclosures as 43.6% of Sampled Peers Run Unsupported Versions

Bitcoin Core changes disclosure policy as 43.6% of sampled peers run unsupported versions

Bitcoin Core is changing how quickly it discloses some vulnerabilities. Developers can now publish fixes and advisories sooner when they believe a flaw would be easy to rediscover. A Karlsruhe Institute of Technology snapshot also found that 3, 671 of 8, 422 observed public peers were running release lines that no longer receive security patches.

• Developers can consider how easily a flaw could be rediscovered.
• KIT found 43.6% of sampled peers on end-of-life versions.
• The snapshot covers visible public IPv4 and IPv6 peers, not every Bitcoin node.
• Bitcoin Core 32.0’s release date was listed as TBA as of Oct. 24.

Faster disclosure for flaws that may be easy to rediscover

Bitcoin Core merged the security-policy change on Oct. 22. The available notice does not specify the year. The status and figures below are reported as of the October dates cited.

The revised policy lets developers consider a vulnerability’s “rediscoverability” during triage. That means assessing how easily someone else might find the same flaw, potentially with help from large language models or other tools. Bitcoin Core developer Antoine Poinsot announced the change on the bitcoindev mailing list. He argued that a long embargo could delay patched releases without offering much protection if attackers could rediscover the flaw.

For vulnerabilities placed in the new category, developers can release fixes across all maintained release lines and publish an advisory as each fix becomes available. At the time, the maintained lines were 29.x, 30.x and 31.x. As of Oct. 23, no specific vulnerability had been publicly identified as belonging to the category.

An embargo is a period when vulnerability details are kept confidential while developers prepare fixes and operators have time to update. Under the previous policy, details of medium- and high-severity flaws stayed confidential until two weeks after the last affected release reached end of life. That wait could stretch close to a year.

The change affects the timing of fixes and disclosure. It does not guarantee that every operator will receive or install a patch immediately. During an embargo, a patched release might be available without details of the vulnerability or an advisory explaining its significance. The new approach gives developers a way to release fixes across maintained lines sooner and publish advisories as the fixes become available.

There is a trade-off. Poinsot warned that faster disclosure gives mitigations less time to prove themselves on development branches. A shorter window for attackers to rediscover a flaw may help, but it does not make testing any less important.

AI is part of the rationale, not proof that a model found any of the vulnerabilities discussed here. The policy treats help from large language models as one possible factor when developers judge how easily a flaw could be rediscovered.

A vulnerability disclosure took about 388 days after the fix

CVE-2024-52911 shows the timeline under the former approach. The high-severity use-after-free affected Bitcoin Core versions later than 0.14.0 and earlier than 29.0. A use-after-free is a memory-management flaw. In this case, a crafted invalid block could crash a node.

The vulnerability was reported in November 2024, fixed in Bitcoin Core 29.0 in April 2025, and disclosed on May 5, 2026, about 388 days after the fix. The timeline helps explain why developers are reconsidering long disclosure delays. One case, though, cannot show how the revised policy will work for different vulnerabilities.

Bitcoin Core 32.0’s release notes also say that three medium- or high-severity flaws fixed in 30.0 would remain undisclosed until two weeks after the new version shipped. The policy change does not promise immediate disclosure of every flaw. It adds a faster route for vulnerabilities developers judge easy to rediscover.

What the KIT node snapshot does and does not show

A Karlsruhe Institute of Technology (KIT) snapshot from Oct. 18 counted 3, 671 of 8, 422 self-reporting Bitcoin Core peers on release lines past end of life, or 43.6%. End of life (EOL) means a release line no longer receives maintenance or security patches.

In a public-peer count like this, visible nodes report information about the software they run when they connect. KIT’s snapshot included public IPv4 and IPv6 peers. It excluded Tor-only nodes, non-listening nodes, and private infrastructure run by exchanges, custodians and miners. The count shows observed peers, not every Bitcoin node or all professionally operated infrastructure.

The reported breakdown lists 3, 243 peers on 31.x, 712 on 30.x and 635 on 29.x. Those figures add up to 4, 590. Adding the 3, 671 peers on unsupported lines gives 8, 261, leaving 161 of the stated 8, 422 unaccounted for. The figures provided do not explain the difference, so the reported percentage should be read with that limitation in mind.

When Bitcoin Core 32.0 ships, 29.x is expected to leave the maintenance window. If the snapshot stayed unchanged, 4, 306 of 8, 422 peers, or 51.1%, would then be on unsupported lines. That is a projection, not a later observed count. It also relies on the same snapshot, whose listed figures leave 161 peers unexplained.

Operators still decide when to upgrade

Bitcoin has no central authority that can compel node operators to install updates. That independence is a core feature of the network. It also means operators and organizations must choose to keep their software up to date.

Operators should check which Bitcoin Core release line they run and whether it still receives patches. They should also review compatibility notes before upgrading. Core 32.0 changes the default partially signed Bitcoin transaction (PSBT) version used by Bitcoin Core from version 0 to version 2. PSBTs coordinate transaction signing, including in multisignature (multisig) setups that require multiple parties to approve a transaction. If you use a mixed-version multisig workflow, check the release notes and your setup before relying on the new default.

Quicker advisories could help operators understand why an update matters. But a policy cannot install patches, and a public-peer snapshot cannot show every private deployment. The real test will be whether developers apply the new category consistently and operators act when fixes are available.

Key questions and answers

• What changed in Bitcoin Core’s security policy?

  Developers can consider how easily attackers might rediscover a flaw. For flaws placed in the new category, they can release fixes across maintained lines and publish advisories as each fix becomes available.

• Why change the disclosure timing?

  Poinsot argued that long embargoes can delay patched releases while offering limited protection if a flaw is easy to rediscover. AI tools are one possible factor in that assessment, not evidence that AI found the cited vulnerabilities.

• How many sampled peers were on unsupported versions?

  KIT reported 3, 671 of 8, 422, or 43.6%, in its Oct. 18 snapshot. The listed version counts leave 161 peers unexplained, and the snapshot excludes several kinds of nodes and infrastructure.

• Will more than half of sampled peers be unsupported when 32.0 ships?

  The projection is 4, 306 of 8, 422, or 51.1%, if the snapshot remains unchanged after 29.x leaves the maintenance window. It is not an observed post-release count.

• When will Bitcoin Core 32.0 be released?

  As of Oct. 24, the project’s life-cycle page listed the date as TBA, with release candidates in the download directory.