Bitcoin Core Overhauls Security Policy for AI-Easy Vulnerabilities

The security disclosure policy of Bitcoin Core has been updated so that vulnerabilities easily discoverable by large language models can be patched faster, putting an end to the extended embargoes that used to apply to such flaws.

The update to Bitcoin Core's security policy was merged by maintainers on Thursday. Antoine Poinsot, a developer at Chaincode Labs, authored the proposal and informed the Bitcoin Development Mailing List about it that same day.

Poinsot observed: “We recently experienced an increase in the number of reports for security vulnerabilities that can be easily (re-)discovered.” He wrote: “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, running on the majority of Bitcoin network nodes, classified each disclosed vulnerability by severity and scheduled disclosure accordingly. Low-severity issues were released two weeks after the subsequent major version came out.

For medium- and high-severity vulnerabilities, the embargo continued until two weeks after the last impacted version reached end of life, a period that could extend up to a year.

Node operators, often slow to upgrade, were given time by the prolonged embargoes to apply patches before vulnerabilities were made public. In effect, this meant fixes were not released for older maintained versions and only came with the next major software release.

Poinsot contended that such a compromise does not work for easily rediscoverable bugs. According to the policy, “The embargo period achieves little but it delays the availability of a fixed release.”

What changes

Under triage, Bitcoin Core can mark a vulnerability as “easily discoverable,” a classification defined by the policy as issues that can be identified “with minimal effort, such as through a simple LLM prompt.” This label can also apply to flaws found through other methods.

For vulnerabilities in this category, the project will backport a patch to all maintained major versions, release point versions immediately, and publish a security advisory with limited information concurrently with the fix.

Poinsot recognized that these fixes would undergo less testing before reaching users.

Vulnerabilities not classified as easily discoverable continue to follow the existing severity-based timeline. Critical issues, such as those that could allow coin theft at the protocol layer, artificially increase the coin supply, or cause an irreversible chain split, remain outside the standard policy and are addressed individually.

Antoine Riard, a developer, advocated for an option to issue a patch without a security advisory and to withhold details case by case. Poinsot refused, stating that notifying users without providing specifics “could create more risk unnecessarily” by causing a rushed migration among users who would not otherwise be impacted.

A summer of AI-driven reports

This policy update comes after months of increased stress on Bitcoin open-source projects. At the end of July, the Bitcoin Red Team, a volunteer group of 16 developers, used AI models to scan 390 bitcoin repositories in roughly 24 hours, recording 4,962 findings, 85 of which were deemed critical.

Within a few days, a BTCPay Server vulnerability that the group had disclosed privately was exploited on production merchant servers, draining Lightning nodes.

In August, Core Lightning developers advised operators to upgrade or disconnect after the project received accurate AI-generated reports.

The Bitcoin Red Team's initiative came after a Coldcard hardware wallet exploit on July 30 where attackers extracted 594 BTC in 25 minutes. Losses from four separate sweeps neared $114 million.