Bitcoin Core will move faster to patch vulnerabilities considered easy to rediscover, while retaining case-by-case discretion over disclosure details and timing.
Bitcoin Core has revised its security-advisory policy to speed fixes for vulnerabilities that are easy to rediscover, a change developers say addresses the shrinking value of keeping some flaws secret in an era of AI-assisted bug hunting.
The policy update, merged on October 22 as pull request #1281, classifies vulnerabilities as “easily discoverable” when they can be found with minimal effort. That can include flaws identified through a simple large language model prompt, but the category is broader: it may also cover vulnerabilities whose fixes would be easy to infer. A Japanese translation commit referring to the change followed on October 23.
For this category, developers intend to backport patches to all currently maintained Bitcoin Core releases and issue point releases as soon as possible, rather than leave users waiting for the next major version. A security advisory is to accompany fixed releases. The change is a practical adjustment to the disclosure process, not a claim that AI can reliably identify every defect or that every reported issue is genuine.
Bitcoin Core developer Antoine Poinsot described the rationale in an email to the Bitcoin Development Mailing List. Under the previous approach, vulnerability details could be held under lengthy embargoes to give users time to upgrade. But secrecy could also delay fixes for older software versions. If a weakness is readily rediscovered, Poinsot argued, the embargo may offer little protection while postponing patched releases.
The new policy does not establish a uniform disclosure clock for every vulnerability. Internal discussion acknowledged that the amount of technical detail released—and, in some cases, the timing of an advisory—may be decided case by case. That discretion is intended to avoid giving attackers useful information before patches have spread. Critical vulnerabilities remain outside the standard timetable and continue to be handled through an ad hoc process.
For lower-severity issues, the existing severity-based schedule remains relevant. The source policy says low-severity vulnerabilities are disclosed two weeks after a major release containing the fix. Medium- and high-severity issues are disclosed two weeks after the last affected release reaches end of life, typically about a year after the fix appears in a new major version. The revised treatment of easily discoverable flaws is designed to shorten that wait where delay offers limited security benefit.
The move comes amid a larger wave of vulnerability reports affecting Bitcoin-related software. On August 6, the 16-person volunteer Bitcoin Red Team reported 4,962 potential issues across 390 projects after 29.8 hours of work. The team rated 720 findings high or critical, but only 21.4% had been reproduced at that point. Those figures underscore both the reach of automated or rapid security review and the need to distinguish candidate reports from confirmed vulnerabilities.
Luke de Wolf, host of the Bitcoin Infinity Show and author of *Defending Bitcoin*, said October 23 that he had previously disagreed with Poinsot’s security approach but viewed the policy update as a good adjustment. His response points to a broader challenge for open-source infrastructure: developers must make fixes available quickly without publishing details that could help exploit unpatched systems.
Bitcoin Core’s change does not eliminate that tradeoff. Instead, it recognizes that disclosure rules built around long periods of secrecy may not fit flaws that researchers can readily uncover again. For a decentralized network dependent on independently operated nodes and widely distributed software, the policy puts faster backports at the center of the response while preserving judgment over how and when sensitive details become public.

