Bitcoin Core’s security policy now has a third disclosure setting, and it exists because of how cheaply a language model can rediscover a bug. A change merged on October 22 adds an “easily discoverable” class of vulnerability, defined as one that can be found with minimal effort, “such as through a simple LLM prompt.” When maintainers apply that label during triage, the usual embargo is set aside: the fix is backported to every maintained branch and shipped as a point release, with a public security advisory, as soon as the patch is ready.
The reasoning is stated plainly in the merged pull request. Antoine Poinsot, the Bitcoin Core contributor who authored the change, wrote that the project is receiving more reports for vulnerabilities that keep getting rediscovered, “largely due to LLMs drastically reducing the bar to find certain classes of issues or identify covert fixes.” An embargo only buys time while a flaw is genuinely hard to find. Once a bug is a single prompt away, secrecy protects nobody and mainly delays the fixed release that node operators actually need.
To see what changed, lay out the old timetable. Low-severity issues were disclosed two weeks after the next major release shipped. Medium- and high-severity issues stayed private until two weeks after the last affected release reached end of life, a window the project itself describes as roughly a year. That made sense for a reference implementation whose operators upgrade slowly, because Bitcoin Core has generally not backported security fixes, delivering them instead with the next major version. The tradeoff was that a patch could sit for months while a patient attacker worked the problem independently.
The new route changes both timing and delivery. An easily discoverable bug no longer waits for a major release. Maintainers commit to backporting the fix to every currently maintained major version and to cutting point releases, so older nodes can upgrade without adopting an entire major version. The severity ladder still governs everything else: low-severity bugs keep the two-week clock, medium and high keep the roughly one-year clock, and critical flaws remain outside the standard policy, handled case by case as before.
The faster path has a real cost, and the maintainers said so. A patch shipped in days receives less review and testing than one that sat in a development branch for months. Poinsot flagged this directly, writing that mitigations “won’t have as much bake time in development branches before being released to users.” The discussion also weighed whether to disclose even earlier, since opening a fix’s pull request can tip off automated watchers, but the merged text keeps the advisory simultaneous with the patch rather than issuing a vague pre-warning.
No vulnerability has been placed in the new class yet, so this is a change of process rather than the disclosure of a live bug. For node operators nothing changes today; the first real test arrives when a triaged report is flagged easily discoverable and point releases land with far less notice than the network is used to. The broader shift is already visible: AI-assisted bug hunting has pushed other Bitcoin projects to act, and the reference implementation has now accepted that a secrecy window is only worth keeping while it still conceals the flaw from the people who would exploit it.
Source: BlockchainReporter.