Bitcoin Core Ends Year-Long Embargo for Easy-to-Find Bugs

Bitcoin Core merged a security policy change on Oct. 22 that ends its roughly year-long disclosure delay for flaws that can be rediscovered with minimal effort. Maintainers will backport fixes to the latest three supported major releases and publish point releases and security advisories as soon as possible.

The policy creates an “easily discoverable” vulnerability class. The classification depends on how much effort is needed to find a flaw again, not on whether artificial intelligence was used. Maintainers will decide whether a vulnerability meets the standard during security triage.

Antoine Poinsot, a Bitcoin Core contributor at Chaincode Labs, announced the change on the Bitcoin Development Mailing List after the relevant pull request was merged. “We recently experienced an increase in the number of reports for security vulnerabilities that can be easily (re-)discovered,” Poinsot wrote. He attributed the increase in part to large language models reducing the effort needed to find some flaws or identify fixes that had not been publicly explained.

“For these issues that are easy to find, this is the wrong tradeoff,” Poinsot wrote. “The embargo period achieves little but it delays the availability of a fixed release.”

Bitcoin Core previously tied disclosure timing to vulnerability severity. Low-severity flaws were generally disclosed two weeks after the next major release. Medium- and high-severity flaws remained private until two weeks after the last affected release reached the end of its support period. That period usually ended about a year after the release containing the fix.

The earlier policy was intended to give node operators time to upgrade. Bitcoin Core is the reference implementation used by most Bitcoin nodes, and operators often adopt new versions slowly. Fixes were generally included in the next major release instead of being backported to older supported branches.

For an easily discoverable flaw, maintainers will now issue targeted fixes for the latest three supported major releases and publish an advisory with the patched software. Operators using older supported versions can install a security update without immediately moving to the newest major release.

The change does not alter the timetable for other vulnerability classes. Low-severity issues retain the two-week disclosure schedule. Medium- and high-severity issues remain subject to the longer timetable unless maintainers classify them as easily discoverable. Critical vulnerabilities continue to be handled individually because they could affect Bitcoin’s monetary rules or cause a permanent chain split.

Poinsot warned that faster releases would leave less time for review and testing. “Mitigations won’t have as much ‘bake time’ in development branches before being released to users,” he wrote.

During the policy discussion, some contributors argued that publishing a fix could reveal a vulnerability’s location to attackers monitoring the project’s repository. Others proposed delaying the advisory or issuing a warning without technical details. The merged policy keeps the advisory simultaneous with the patched release.

No vulnerability has yet been assigned to the new class. The policy will first be tested when maintainers identify a qualifying flaw and release patches for the supported branches. Earlier in 2026, Core Lightning maintainers told node operators to upgrade or disconnect after AI-generated vulnerability reports were confirmed.