Bitcoin Core has shortened the path from vulnerability triage to fixes across maintained release branches, as a survey shows nearly half of sampled public peers are running unsupported versions.
Bitcoin Core has changed its security policy to speed the release of fixes for vulnerabilities that are judged easy to rediscover and exploit, a shift that comes as a Karlsruhe Institute of Technology snapshot found that 43.6% of sampled public peers were running unsupported versions. According to the project’s updated policy, developers can now classify a flaw at triage and, if it fits the new standard, backport the fix across every maintained release line at once while publishing an advisory as each patch lands.
The move reflects growing concern that modern AI tools make it easier to reproduce weaknesses that once might have stayed hidden during a long embargo. Bitcoin Core developer Antoine Poinsot said on the bitcoindev mailing list that the earlier approach often delayed fixed releases without delivering much extra protection, although the shorter timetable also gives mitigations less time to prove themselves on development branches. As of 23 October, no bug had yet been assigned to the new category publicly.
Under the old system, medium- and high-severity defects were generally kept confidential until two weeks after the end of life of the last affected release, a period that could stretch close to a year. The project’s handling of CVE-2024-52911 illustrates the gap: the use-after-free in block validation was reported in November 2024, fixed in version 29.0 in April 2025 and not publicly disclosed until 5 May 2026, roughly 388 days later. The release notes for version 32.0 also say three medium- or high-severity bugs fixed in 30.0 remain under wraps until the same disclosure window expires.
The support picture is already strained. Bitcoin Core currently maintains only its three newest major branches, 29.x, 30.x and 31.x, while the KIT snapshot taken on 18 October counted 3,671 of 8,422 self-reported public peers on versions already past end of life. That left 3,243 peers on 31.x, 712 on 30.x and 635 on 29.x, with the sample excluding Tor-only nodes, non-listening nodes and private infrastructure run by exchanges, custodians and miners.
The unsupported share is likely to rise further once version 32.0 arrives, because 29.x will then fall out of the maintenance window. On the KIT figures, that would leave 4,306 of 8,422 peers, or 51.1%, on unsupported releases if the sample pattern did not change. The project’s life-cycle page still listed the 32.0 release date as to be announced as of 24 October, and the release also changes the default partially signed Bitcoin transaction format from version 0 to version 2, a detail that matters for multisig setups that mix older and newer nodes. In practice, Bitcoin’s security depends on operators choosing to upgrade, because there is no central authority that can force them to do so.
Disclaimer: This content is intended for informational purposes only. Readers are advised to exercise their own judgement, conduct due diligence, or consult a qualified expert before acting on any information provided.
