Bitcoin Core drops disclosure embargo for vulnerabilities AI can easily find
Coinyong
BTC
Bitcoin Core created a new "easily discoverable" vulnerability category in a policy change on Oct. 22.
Such flaws get fixed releases for all maintained versions and a security advisory as soon as possible.
Other bugs keep severity-based timelines, with Medium and High disclosed about a year after the first fixed release.
Bitcoin Core will no longer hold back disclosure of security vulnerabilities that are easy enough to find with a single prompt to an AI model. Developers of Bitcoin Core, the main node software for the Bitcoin network, will classify such flaws as "easily discoverable" and release fixed versions together with a security advisory as soon as possible. Developer Antoine Poinsot announced the change on the Bitcoin development mailing list on Oct. 22 (UTC), and the security policy page on the project's official website was updated the same day.
No waiting for bugs a single prompt can find
"We recently experienced an increase in the number of reports for security vulnerabilities that can be easily (re-)discovered," Poinsot wrote. "This is largely due to LLMs drastically reducing the bar to find certain classes of issues or identify covert fixes." He said that because of the project's nature and node operators' slow upgrade culture, Bitcoin Core has favored long disclosure embargoes, which generally meant security fixes could not be backported to older versions and only reached users with the next major release.
Under the revised policy, whether a report is easily discoverable is decided at triage. The policy page defines the category as vulnerabilities "that can be discovered with minimal effort, such as through a simple LLM prompt," and Poinsot said the classification is not restricted to issues found with AI. For those issues, the project will backport the fix to every maintained major version, publish point releases as soon as possible and release a security advisory along with them. "The embargo period achieves little but it delays the availability of a fixed release," Poinsot wrote of such issues.
What stays the same and what changes by severity
Vulnerabilities not classified as easily discoverable will still be disclosed on the existing severity-based timelines. The updated policy page sets out the following disclosure schedule.
| Easily discoverable (new) | Fixed releases for every maintained major version and a security advisory published together as soon as possible, without severity-based embargoes |
|---|---|
| Low | Disclosed 2 weeks after the release of a major version containing the fix |
| Medium and High | Disclosed 2 weeks after the last affected release reaches end of life, about a year after a major version containing the fix was first released |
| Critical | Not covered by the standard policy and handled case by case |
For embargoed vulnerabilities, a pre-announcement giving only the number of fixed vulnerabilities and their severity levels is made two weeks before the details are released, coinciding with a new major release. The policy page defines critical bugs as those that allow coin theft at the protocol level, the creation of coins outside the specified issuance schedule, or permanent, network-wide chain splits.
Publish the advisory right away, or hold it back?
The proposed change was posted on GitHub on Oct. 16, received approval from several developers and was merged on Oct. 22. During the discussion, developers disagreed over when the security advisory should be published.
Antoine Riard
Riard proposed wording for an accelerated exception process, which he called a "derogatory process," that would ship fixes quickly regardless of severity while leaving it to the project's discretion whether the advisory comes out with the fix or later. His point was that AI-generated reports usually do not include a full exploitation scenario, so less information should be released while a fix is still being rolled out.
Antoine Poinsot
Poinsot opposed the idea, saying a warning without details could create unnecessary risk by pushing users who would not otherwise be affected into a rushed migration. He gave the example of a block template creation bug, for which miners should update immediately while merchants can afford a more careful upgrade.
The final text commits to publishing the advisory together with the fixed releases. Earlier in the discussion, Poinsot told another developer that "covertly patching such vulnerability would achieve little: they can already be found through a trivial LLM scan," while adding that the project should still avoid unnecessarily calling attention to such fixes as a baseline. He also acknowledged that under the new policy, fixes will have less time to be tested in development before reaching users.
Fixes will ship across versions 31, 30 and 29
Bitcoin Core maintains its three latest major versions. Versions 31.x, released in April, 30.x and 29.x are currently supported, and the most recent point releases are 31.1, 30.3 and 29.4, published in July. Under the new policy, fixes for easily discoverable vulnerabilities will go into all three lines, so operators can get patches without switching major versions. Support for 28.x ended in April.
Bitcoin traded at around 108.5 million won on the Korean exchange Upbit at about 12:30 p.m. KST on Oct. 24. The Upbit price was 1.1% to 1.2% higher than the Binance price of around $81,000 converted to won.
More crypto news
INIT
ETH