Bitcoin Core has changed its security disclosure policy to speed up fixes for vulnerabilities that large language models can find with little effort, ending the months-long embargoes those bugs once received.
Maintainers merged the change to the project’s security policy on Thursday. Chaincode Labs developer Antoine Poinsot, who wrote the proposal, announced it in a message to the Bitcoin Development Mailing List the same day.
“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.”
How the policy worked before
Bitcoin Core, the software that runs on most nodes in the Bitcoin network, has graded each reported vulnerability by severity and timed its disclosure to match. Low-severity flaws were made public two weeks after the next major version shipped.
Medium- and high-severity issues stayed under embargo until two weeks after the last affected release reached end of life, a span that could stretch to a year.
The extended timelines gave node operators, many of whom upgrade at a slow pace, time to move to patched software before details became public. In practice, the approach meant fixes went unreleased for older maintained versions and arrived with the next major release.
Poinsot argued that this tradeoff fails for bugs that are easy to rediscover. “The embargo period achieves little but it delays the availability of a fixed release,” the policy reads.
What changes
During triage, Bitcoin Core can flag a vulnerability as “easily discoverable,” a category the policy defines as issues that can be found “with minimal effort, such as through a simple LLM prompt.” The label is open to flaws found by other means as well.
For those issues, the project will backport a fix to every maintained major version, cut point releases as soon as possible and publish a security advisory with some details at the same time as the fixed software.
Poinsot acknowledged that such fixes will have less testing time before they reach users.
Vulnerabilities outside that category keep the existing severity-based schedule. Critical bugs, those that could enable coin theft at the protocol level, inflate the supply or cause a permanent chain split, remain outside the standard policy and will be handled case by case.
Developer Antoine Riard pushed for an option to ship a fix without an advisory and withhold details on a case-by-case basis. Poinsot declined, writing that alerting users without details “could create more risk unnecessarily” by prompting a rushed migration among users who would otherwise be unaffected.
A summer of AI-driven reports
The change follows months of heightened pressure on Bitcoin’s open-source projects. In late July, a volunteer group of 16 developers known as the Bitcoin Red Team ran AI models across 390 bitcoin repositories in about a day and logged 4,962 findings, including 85 rated critical.
Within days, a BTCPay Server flaw the group had reported in private was exploited on live merchant servers, draining Lightning nodes.
In August, Core Lightning developers told operators to upgrade or disconnect after AI-generated reports to the project proved accurate.
The Red Team effort followed a Coldcard hardware wallet exploit in which attackers drained 594 BTC in 25 minutes on July 30. Losses across four sweeps approached $114 million.
Bitcoin Core has changed its security disclosure policy to speed up fixes for vulnerabilities that large language models can find with little effort, ending the months-long embargoes those bugs once received.
Maintainers merged the change to the project’s security policy on Thursday. Chaincode Labs developer Antoine Poinsot, who wrote the proposal, announced it in a message to the Bitcoin Development Mailing List the same day.
“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.”
How the policy worked before
Bitcoin Core, the software that runs on most nodes in the Bitcoin network, has graded each reported vulnerability by severity and timed its disclosure to match. Low-severity flaws were made public two weeks after the next major version shipped.
Medium- and high-severity issues stayed under embargo until two weeks after the last affected release reached end of life, a span that could stretch to a year.
The extended timelines gave node operators, many of whom upgrade at a slow pace, time to move to patched software before details became public. In practice, the approach meant fixes went unreleased for older maintained versions and arrived with the next major release.
Poinsot argued that this tradeoff fails for bugs that are easy to rediscover. “The embargo period achieves little but it delays the availability of a fixed release,” the policy reads.
What changes
During triage, Bitcoin Core can flag a vulnerability as “easily discoverable,” a category the policy defines as issues that can be found “with minimal effort, such as through a simple LLM prompt.” The label is open to flaws found by other means as well.
For those issues, the project will backport a fix to every maintained major version, cut point releases as soon as possible and publish a security advisory with some details at the same time as the fixed software.
Poinsot acknowledged that such fixes will have less testing time before they reach users.
Vulnerabilities outside that category keep the existing severity-based schedule. Critical bugs, those that could enable coin theft at the protocol level, inflate the supply or cause a permanent chain split, remain outside the standard policy and will be handled case by case.
Developer Antoine Riard pushed for an option to ship a fix without an advisory and withhold details on a case-by-case basis. Poinsot declined, writing that alerting users without details “could create more risk unnecessarily” by prompting a rushed migration among users who would otherwise be unaffected.
A summer of AI-driven reports
The change follows months of heightened pressure on Bitcoin’s open-source projects. In late July, a volunteer group of 16 developers known as the Bitcoin Red Team ran AI models across 390 bitcoin repositories in about a day and logged 4,962 findings, including 85 rated critical.
Within days, a BTCPay Server flaw the group had reported in private was exploited on live merchant servers, draining Lightning nodes.
In August, Core Lightning developers told operators to upgrade or disconnect after AI-generated reports to the project proved accurate.
The Red Team effort followed a Coldcard hardware wallet exploit in which attackers drained 594 BTC in 25 minutes on July 30. Losses across four sweeps approached $114 million.
