Bitcoin Core Speeds Up Fixes for Easily Found Vulnerabilities, Disclosing Them Without the Usual Embargo

Key Facts

Bitcoin Core merged a change to its security vulnerability disclosure policy on October 22, 2026, speeding up fixes and disclosures for issues that are easy to find, according to the GitHub merge record. The new process calls for a point release containing the fix for every supported major release, along with a security advisory, as soon as possible. The change does not alter Bitcoin network consensus rules; it concerns the timing of vulnerability fixes and user notifications. The move came after the proposal’s developer said large language models had significantly lowered the bar for finding some types of issues or identifying hidden fixes. The project says the usual wait before disclosure offers little benefit when a vulnerability is easy to find, while delaying fixes reaching users.

The policy defines an easily found vulnerability as one that can be discovered with limited effort, such as by using a simple prompt with a large language model. It does not restrict this classification to issues found by models, since the criterion concerns how easy the vulnerability is to find in general. The proposal’s developer said reports of vulnerabilities that are easy to rediscover had increased, linking this to models’ ability to lower the bar for finding certain classes of issues or hidden fixes. The rule changes the starting point for disclosure: instead of waiting for a uniform deadline tied to severity, the project follows a faster process when a vulnerability is easy to find. This allows the update and security advisory to be published at the same time, according to the policy, while keeping fixes tied to major releases that remain under maintenance.

The previous policy gave users a waiting period before vulnerability details were disclosed. Low-severity vulnerabilities were disclosed two weeks after the release of the major version containing the fix. For medium- and high-severity vulnerabilities, disclosure came two weeks after the last affected release went out of service, or about a year after the release of the major version that carried the fix. The change replaces these usual deadlines for easily found vulnerabilities with the release of the update and advisory as soon as possible, without waiting for the previous severity-based schedules. This reflects a different balance between keeping vulnerability details confidential and giving users time to update, particularly when others are likely to find the issue before the embargo period ends.

The timing’s impact depends on how the software is maintained. According to the proposal’s developer, users’ slow upgrade pace means a long embargo delays fixes reaching them, while security fixes are not usually backported to earlier releases and instead become available with the next major release. Bitcoin Core always maintains the latest 3 major releases; when a new major release comes out, the oldest leaves the maintenance window and becomes end-of-life. The lifecycle policy says the project provides minor releases dedicated to fixing bugs, both security-related and otherwise, for each major release. The new process therefore ties the fix to every major release that remains supported, allowing the vulnerability to be addressed within the existing maintenance scope instead of waiting for the next major release for users.

But faster availability may reduce the time a fix spends in testing before reaching users. CoinDesk said fixes taking the fast track “will not have as much time for testing” before release. The trade-off is between reducing the time an issue remains unfixed and allowing more time to test the update before distribution. In its definition of critical vulnerabilities, Bitcoin Core’s policy points to issues that threaten the fundamental security and integrity of the entire Bitcoin network, such as protocol-level theft of coins, creation of coins outside the issuance schedule, or a permanent chain split. The policy exempts this category from the standard disclosure schedule and says it may require case-by-case action; the process specified for easily found vulnerabilities therefore does not automatically apply to them.

The policy change comes amid broader security checks of Bitcoin-related projects. CoinDesk reported that the volunteer Bitcoin Red Team, made up of 16 developers, used artificial intelligence models to examine 390 Bitcoin-related projects in about one day in late July 2026. The team recorded 4,962 findings, classifying 85 as critical. These figures relate to the results of scans of Bitcoin projects and do not in themselves establish that a vulnerability in Bitcoin Core was exploited. Nor does the new disclosure policy announce the discovery of a specific vulnerability in the software; it sets out how vulnerabilities classified as easy to find are handled, while critical vulnerabilities remain outside the usual disclosure schedule.