Bitcoin Core has revised its security disclosure practices in response to large language models that have sharply lowered the barrier for rediscovering certain software flaws.
The change prioritizes faster delivery of patches for issues that can be identified with minimal effort, while retaining longer timelines for other categories of vulnerabilities.
In a message to the Bitcoin Development Mailing List, developer Antoine Poinsot noted a recent rise in reports of vulnerabilities that are easy to rediscover.
He attributed much of this increase to LLMs, which have reduced the expertise and time required to locate certain classes of bugs or spot covert fixes.
Traditional disclosure strategies, he explained, always involve a tension between openness—which equalizes knowledge between defenders and potential attackers—and the need to give node operators sufficient time to upgrade before details become public.
Because of Bitcoin Core’s architecture and the relatively slow pace at which many users update, the project has historically favored extended embargo periods.
Under that approach, security fixes were typically withheld from older maintained releases and made available only with the next major version.
For flaws that are now straightforward to rediscover, Poinsot argued that this tradeoff no longer holds.
An embargo provides little meaningful protection while postponing the release of corrected software.
The updated policy therefore introduces a practical classification for “easily discoverable” vulnerabilities—those that can be found with minimal effort, such as through a simple prompt to an LLM.
The designation is not limited exclusively to AI-assisted findings.
During triage, such issues may be flagged accordingly.
For these cases, the project will backport fixes to all currently maintained major versions and issue point releases as quickly as possible.
A security advisory containing some details will be published at the same time as the fixed releases, bypassing the standard severity-dependent embargo periods.
Vulnerabilities that do not meet this threshold continue to follow the existing severity framework.
Low-severity issues are disclosed two weeks after a major version containing the fix is released.
Medium- and high-severity issues are disclosed two weeks after the last affected release reaches end of life, which typically occurs roughly a year after the major version that first included the fix.
Critical bugs—those that could enable coin theft at the protocol level, inflate the money supply, or cause permanent network-wide chain splits—remain outside the standard policy and are handled on a case-by-case basis.
Some reported issues may also be deemed serious enough to warrant immediate attention without an embargo, or may not qualify as vulnerabilities at all.
The shift reflects broader pressures across Bitcoin’s software ecosystem, where AI-assisted research has generated higher volumes of vulnerability reports.
By accelerating patches and concurrent advisories for the most readily rediscoverable problems, Bitcoin Core aims to shorten the window during which easily found flaws remain unpatched on maintained releases, while still preserving measured disclosure schedules for harder-to-exploit issues.