Bitcoin Core has adjusted its vulnerability disclosure policy to accelerate patches for security flaws that large language models can easily detect, eliminating the lengthy embargoes previously applied to those issues.
Project maintainers merged the update into the software’s security guidelines on Thursday. Antoine Poinsot, a developer at Chaincode Labs who authored the proposal, shared the announcement via a Bitcoin Development Mailing List message that same day.
“We recently experienced an increase in the number of reports for security vulnerabilities that can be easily (re-)discovered,” Poinsot explained. “This is largely due to LLMs drastically reducing the bar to find certain classes of issues or identify covert fixes.”
How the policy worked before
Bitcoin Core—the software powering the majority of nodes across the Bitcoin network—previously evaluated each reported security flaw by severity to determine its disclosure timeline. Low-severity bugs were disclosed publicly two weeks following the release of the subsequent major version.
Meanwhile, medium- and high-severity vulnerabilities remained under wraps until two weeks after the final affected release reached its end of life, a duration that could extend up to a year.
These prolonged schedules provided node operators, many of whom update software slowly, sufficient time to transition to patched versions before public disclosure. Practically speaking, this meant fixes for older supported versions were delayed until the rollout of the next major version.
Poinsot contended that this methodology breaks down when applied to flaws that are simple to find again. “The embargo period achieves little but it delays the availability of a fixed release,” the updated policy states.
What changes
Under the new framework, Bitcoin Core evaluators can designate a vulnerability as “easily discoverable.” The policy classifies this as any issue detectable “with minimal effort, such as through a simple LLM prompt,” though the label also applies to flaws uncovered through other methods.
When handling these specific issues, the project will backport patches to all maintained major versions, issue point releases immediately, and release a security advisory containing relevant details alongside the updated software.
Poinsot noted that these accelerated fixes will undergo less testing before reaching end users.
Flaws falling outside this designation will continue to follow the traditional severity-based timeline. Critical vulnerabilities—such as those capable of causing protocol-level coin theft, supply inflation, or permanent chain splits—stay outside the standard policy and will be evaluated individually.
Developer Antoine Riard advocated for an alternative approach allowing patches to ship without an advisory, withholding specific details on a case-by-case basis. Poinsot rejected the suggestion, noting that warning users without providing details “could create more risk unnecessarily” by triggering hurried migrations among users who otherwise faced no threat.
A summer of AI-driven reports
This policy shift arrives on the heels of several months of intensified strain on open-source Bitcoin projects. In late July, a 16-person volunteer group called the Bitcoin Red Team deployed artificial intelligence models across 390 bitcoin repositories over the course of roughly a day, generating 4,962 findings, which included 85 classified as critical.
Shortly after, a BTCPay Server vulnerability privately reported by the group was exploited on active merchant servers, resulting in drained Lightning nodes.
By August, Core Lightning developers urged node operators to either update their software or disconnect entirely after AI-generated vulnerability reports submitted to the project proved to be correct.
The Red Team initiative followed a security breach involving a Coldcard hardware wallet where attackers made off with 594 BTC in a 25-minute window on July 30. Total losses spanning four separate attacks neared $114 million.
Frequently Asked Questions
Why did Bitcoin Core change its security disclosure policy?
Bitcoin Core updated its policy because large language models (LLMs) have made it significantly easier to quickly find certain vulnerabilities or identify covert fixes, rendering long embargo periods ineffective and counterproductive.
What defines an “easily discoverable” vulnerability under the new rules?
The policy defines easily discoverable vulnerabilities as issues that can be found with minimal effort, such as through a simple LLM prompt, though the label also applies to flaws uncovered via other methods.
How are critical bugs handled under the updated policy?
Critical bugs—such as those enabling protocol-level coin theft, supply inflation, or permanent chain splits—remain outside the standard policy and are addressed on a case-by-case basis.
