April

Core

Bitcoin

<p>Bitcoin Core merged a rule change on Oct. 22 that opens a faster lane for vulnerability fixes: a flaw judged easy for attackers to find again can now be patched across every maintained release line at once, with an advisory published as each fix lands. The change comes as a network snapshot from the Karlsruhe Institute of Technology (KIT) shows 43.6% of sampled public Bitcoin Core peers running versions that no longer receive patches.</p>
<p>Under the new rule, developers can classify a flaw at triage, judging how readily it can be turned up again, including with the help of large language models. Bitcoin Core developer Antoine Poinsot announced the change on the bitcoindev mailing list in <a href="https://github.com/bitcoin-core/bitcoincore.org/pull/1281" rel="noopener noreferrer nofollow">the merged pull request updating the project’s security policy</a>. He argued the old embargo achieves little while it delays the availability of a fixed release. The trade-off he flagged is that mitigations get less time to prove themselves on development branches. As of Oct. 23, the new category had not yet been applied publicly to any specific bug.</p>
<p>The change ends a policy that held medium- and high-severity bug details until two weeks past the end of life of the last affected release, a span that could stretch close to a year. Embargo, the period during which vulnerability details stay withheld until fixed releases are widely deployed, has relied on bugs being hard to rediscover. AI tools weaken that assumption, so long silences now delay fixes more than they protect operators.</p>
<h2 id="how-the-old-policy-played-out">How the old policy played out</h2>
<p>The project’s practice is visible in <a href="https://bitcoincore.org/en/2026/05/05/disclose-cve-2024-52911/" rel="noopener noreferrer nofollow">the disclosure of CVE-2024-52911</a>. The high-severity use-after-free in block validation, which affected versions later than 0.14.0 and earlier than 29.0 and let a crafted invalid block crash a node, was reported in November 2024, fixed in 29.0 in April 2025 and disclosed on May 5, 2026, about 388 days after the fix. The pattern continues: the 32.0 release notes state that three medium- or high-severity flaws corrected in version 30.0 stay under wraps until two weeks after the new version ships.</p>
<h2 id="the-unsupported-share">The unsupported share</h2>
<p>Bitcoin Core maintains only its three newest major release lines, currently 29.x, 30.x and 31.x. The KIT snapshot from Oct. 18 counted 3,671 of 8,422 self-reported Bitcoin Core peers on lines already past end of life, with the rest on 31.x (3,243), 30.x (712) and 29.x (635). The count covers public IPv4 and IPv6 peers only, so Tor-only nodes, non-listening nodes and privately run exchange, custodian and miner infrastructure fall outside it. Readers who want the basics can start with <a href="https://insidebitcoins.com/crypto/what-are-crypto-nodes" rel="noopener noreferrer nofollow">what crypto nodes are and how they work</a>.</p>
<p>The share is set to grow. When version 32.0 ships, 29.x leaves the maintenance window, and a projection from the snapshot puts 4,306 of the 8,422 peers, or 51.1%, on unsupported lines if the sample stayed unchanged. The project’s <a href="https://bitcoincore.org/en/lifecycle/" rel="noopener noreferrer nofollow">life cycle page</a> still listed the 32.0 release date as TBA as of Oct. 24, with only release candidates in the download directory.</p>
<p>Core 32.0 also switches the default partially signed Bitcoin transaction format from version 0 to version 2, which matters for multisig setups mixing old and new nodes. Because Bitcoin has no central authority to force upgrades, network security depends on operators choosing to update.</p>

Bitcoin Core fast-tracks security fixes as 44% of sampled nodes run unsupported versions

Table of Contents

Inside Bitcoins

Other articles published on Oct 26, 2026

Join our free newsletter for daily crypto updates!