Bitcoin Core Speeds Fixes for LLM-Findable Bugs

Bitcoin Core will stop sitting on fixes for security bugs that almost anyone could find. Under a change to the project’s security disclosure policy, flaws that “can be discovered with minimal effort, such as through a simple LLM prompt” will get a fixed point release for every maintained version “as soon as possible”, together with a security advisory. Until now, the most serious of these could stay undisclosed for about a year.

The reason is the spread of AI models that can read code. The developers behind the change say large language models (LLMs) have made certain classes of bug so cheap to find that keeping them quiet no longer buys users much time. No new vulnerability was disclosed alongside the change; it is a rule about how future fixes reach the people running nodes. TSN tracks attacks on crypto infrastructure in its crypto hacks and exploits hub.

Easy-to-find bugs now skip the severity-based waiting periods

Bitcoin Core sorts reported vulnerabilities into four classes: Critical, High, Medium and Low. Under the standard rules, which still apply to everything else, Low-severity bugs are disclosed two weeks after a major release containing the fix. Medium and High bugs are disclosed two weeks after the last affected release reaches end of life, which the policy puts at “approximately a year” after the fix first shipped. Critical bugs are handled case by case.

The new category cuts across those classes. For bugs the project judges “easily discoverable”, the policy now says it will publish fixes for each maintained major version “without applying the standard severity-dependent embargo periods”. In practice that means backporting a patch to older supported versions straight away, rather than leaving it in the next major release. The practical difference for node operators is real: TSN found earlier this month that a Bitcoin Core privacy fix had reached the 32.0 code while its 31.x backport was still open.

The change was proposed on 16 October in pull request #1281 on the project’s website repository and merged on 22 October. It adds ten lines to the policy page, and four contributors signed off on the final version.

Developers say AI scanning has made quiet fixes pointless

The proposal, from the contributor known on GitHub as darosior, says the project had “recently experienced an increase in the number of reports for security vulnerabilities that can be easily (re-)discovered. This is largely due to LLMs drastically reducing the bar to find certain classes of issues or identify covert fixes.” The last point matters: a patch that silently closes a hole can itself be read as a map to the hole.

He framed every disclosure policy as a trade-off between transparency and “giving users sufficient time to upgrade”. Because of a “slow upgrade culture” among node operators, Bitcoin Core had favoured long embargoes. “For these issues that are easy to find, this is the wrong tradeoff. The embargo period achieves little but it delays the availability of a fixed release,” he wrote. In a later comment he added that “Covertly patching such vulnerability would achieve little: they can already be found through a trivial LLM scan, and aggressively backporting the patch will give it away anyhow.”

Reviewer stickies-v described the risk of the old approach: “It is now so cheap for multiple attackers to quickly and automatically monitor the repo, that we might end up in a situation where we alert a large amount of attackers by opening the PR, but alert most of our users only days (or weeks) later.” He expected the promise to disclose only after a release to become “increasingly hard to hold”.

Not everyone agreed on the details. Contributor ariard suggested the project could issue an advisory at the moment a fix is written, before a release exists. Darosior replied that, for less-than-critical bugs, alerting users before they have a fixed version to install “would do more harm than good”. He also conceded a cost of moving faster: fixes “won’t have as much ‘bake time’ in development branches before being released to users.”

Bitcoin Core is not alone in rethinking the process. This week Trend Micro’s Zero Day Initiative sent unpatched Linux kernel reports to public lists, and Anthropic said Claude found hundreds of bugs while proving open-source code crash-free. Epoch AI, meanwhile, estimates that open-weight models trail closed ones on cyber skills by only six to seven months.

Speed now protects users better than secrecy does

The old embargo rested on an assumption that the people who knew about a bug were mostly the reporter and the maintainers. For flaws that a cheap automated scan can surface, that assumption no longer holds, and a long silence mainly protects the head start of whoever found the bug first. Shipping the fix to every supported version at once gives defenders the same information attackers are likely to have, with a patch to go with it.

The cost falls on operators. A published advisory with a fix creates a window in which every node that has not upgraded is known to be vulnerable, and Bitcoin Core’s own developers describe its users as slow to update. Exchanges, custodians and payment firms that run their own nodes will need patch processes that can act on a point release within days, not treat upgrades as an annual job. Less testing time before release also raises the chance of a faulty fix in software where mistakes are expensive.

The other open question is judgement. “Minimal effort” is not a precise test, and the policy leaves the classification to the maintainers. How many future advisories carry the “easily discoverable” label, and how quickly the point releases follow, will show whether faster really is the new default.