Bitcoin Core has updated its security disclosure policy to accelerate the patching of vulnerabilities that large language models can easily detect, ending the typical months-long embargo period for such vulnerabilities.
The maintainer merged this change to the project's security policy on Thursday. Antoine Poinsot, a developer at Chaincode Labs, drafted the proposal and announced the change on the same day via the Bitcoin Development Mailing List.
Poinsot wrote: "We have recently experienced an increase in the number of security vulnerability reports that can be easily (re)discovered. This is largely due to LLMs significantly lowering the barrier to identifying certain classes of issues or recognizing subtle fixes."
How did the previous policy work?
Bitcoin Core is the software running on the majority of nodes on the Bitcoin network; it classifies each reported vulnerability by severity and schedules disclosure accordingly. Low-severity issues are disclosed two weeks after the next major release.
Medium and high-severity issues will remain locked until two weeks after the last affected version reaches its end of life, a process that can last up to one year.
The extended timeline gives node operators time to upgrade their software to the patched version before details are made public. In practice, this means that fixes on older, maintained versions will not be released immediately but will instead arrive with the next major release.
Poinsot argues that this trade-off does not hold for vulnerabilities that are easily rediscoverable. The policy states: "The lock-up period has little effect, merely delaying the availability of the fix."
What changes have been made?
During the triage phase, Bitcoin Core may label a vulnerability as “easy to discover,” a policy-defined term for issues that require minimal effort to find, such as through a simple LLM prompt. This label also applies to flaws discovered by other means.
For such issues, the project will backport fixes to all actively maintained major versions, release patch versions as soon as possible, and publish a security advisory with partial details alongside the fixed software.
Poinsot acknowledged that such fixes have less testing time before being delivered to users.
Vulnerabilities outside this category will continue to follow the existing severity-based timeline. Critical vulnerabilities—those that could lead to coin theft, supply inflation, or permanent chain forks at the protocol level—remain exempt from standard policies and will be handled on a case-by-case basis.
Developer Antoine Riard previously proposed an option to deploy fixes without public announcement and disclose details on a case-by-case basis. Poinsot rejected this suggestion, writing that alerting users without details could “unnecessarily create more risk,” as it might prompt users who are unaffected to migrate prematurely.
A summer of surging AI-driven reports
This change comes after months of pressure on the Bitcoin open-source project. In late July, a volunteer group of 16 developers called Bitcoin Red Team used AI models to scan 390 Bitcoin repositories within approximately one day, documenting 4,962 findings, 85 of which were rated as critical.
A few days later, a vulnerability in BTCPay Server reported privately by the team was exploited on a live merchant server, resulting in the draining of funds from the Lightning node.
In August, Core Lightning developers requested operators to upgrade or disconnect after AI-generated reports were confirmed to be accurate.
The Bitcoin Red Team's actions occurred after a vulnerability in the Coldcard hardware wallet was exploited on July 30, during which attackers transferred 594 BTC within 25 minutes. The losses from the four transfers amounted to nearly $114 million.