Bitcoin Core has officially overhauled its security disclosure policy, moving swiftly to eliminate the long-standing embargoes that once guarded software vulnerabilities. The change, designed to accelerate patch deployment, is a direct response to the rapid rise of large language models (LLMs) that have drastically lowered the barrier for automated code analysis and exploit discovery.
Maintainers formally merged the updated policy into the project’s security repository on Thursday. Chaincode Labs developer Antoine Poinsot, who authored the proposal, announced the critical pivot in a message to the Bitcoin Development Mailing List on the very same day, signaling a new era of defensive cybersecurity in decentralized software development.
"We recently experienced an increase in the number of reports for security vulnerabilities that can be easily (re-)discovered," Poinsot wrote in his mailing list announcement. "This is largely due to LLMs drastically reducing the bar to find certain classes of issues or identify covert fixes."
How the Policy Worked Before
As the reference software powering the vast majority of validating nodes across the global Bitcoin network, Bitcoin Core has historically relied on a structured, severity-based disclosure timeline. Under the traditional framework, every reported vulnerability was carefully graded based on its potential impact, and the timeline for making details public was timed accordingly.
Low-severity flaws were typically held in confidence and made public two weeks after the subsequent major software version shipped. Meanwhile, medium- and high-severity issues remained strictly under embargo until two weeks after the final affected release reached its official end of life—a conservative span that could stretch up to an entire year in certain circumstances.
The rationale behind these extended timelines was straightforward: it bought valuable time for node operators, many of whom intentionally upgrade at a slow, deliberate pace to ensure network stability, allowing them to transition to patched software well before technical details or exploit code became public knowledge. In practical terms, however, this meant that security fixes for older, still-maintained versions often went unreleased, delayed deliberately until the arrival of the next major software release cycle.
Poinsot argued that this long-term security tradeoff fundamentally fails when applied to bugs that can be effortlessly rediscovered by modern automated tooling. "The embargo period achieves little but it delays the availability of a fixed release," the revised policy states, highlighting the obsolescence of traditional timelines in the face of modern artificial intelligence.
What Changes Under the New Framework
Under the newly adopted policy, the Bitcoin Core triage process introduces a critical new category. Maintainers can now flag a vulnerability as "easily discoverable," defined explicitly in the policy guidelines as issues that can be uncovered "with minimal effort, such as through a simple LLM prompt." While tailored heavily toward AI-driven discoveries, this classification remains flexible enough to encompass flaws found through other rapid reconnaissance methods.
For vulnerabilities falling into this designation, the project’s protocol changes significantly. Maintainers will immediately backport a fix to every actively maintained major version, cut point releases as rapidly as possible, and publish a formal security advisory containing technical details at the exact same moment the fixed software becomes available to the public.
Poinsot openly acknowledged that bypassing traditional multi-month embargoes means such fixes will inevitably have less real-world testing time before reaching users. Nonetheless, maintainers deem this a necessary risk compared to the alternative of keeping a patch hidden while malicious actors or automated scripts independently discover the exact same flaw.
Vulnerabilities that fall outside the "easily discoverable" category will retain the project’s existing severity-based disclosure schedule. Furthermore, true critical bugs—defined as those capable of enabling protocol-level coin theft, unauthorized supply inflation, or causing a permanent, catastrophic network chain split—remain entirely outside the standard policy framework and will continue to be handled on an individual, case-by-case basis.
During the policy discussions, developer Antoine Riard pushed for an option that would allow maintainers to ship a fix without an accompanying advisory, withholding granular technical details on a case-by-case basis. However, Poinsot declined the suggestion. He noted in the policy text that alerting users to an unspecified vulnerability without providing details "could create more risk unnecessarily," as it would likely prompt a panicked, rushed migration among node operators who might otherwise remain unaffected by the specific flaw.
A Summer of AI-Driven Reports
The swift policy change follows months of mounting pressure on open-source cryptocurrency projects, driven by an unprecedented wave of AI-assisted security audits. In late July, a volunteer collective of 16 developers operating as the Bitcoin Red Team deployed advanced artificial intelligence models across 390 separate Bitcoin-related repositories. In roughly 24 hours, the automated sweep logged 4,962 findings, an astonishing total that included 85 vulnerabilities rated as critical.
The real-world dangers of this automated capability became starkly apparent within days. A flaw in BTCPay Server that had been privately reported by the red team was actively exploited on live merchant servers, resulting in the draining of operational Lightning network nodes.
Shortly thereafter, in August, Core Lightning developers felt compelled to issue an urgent directive instructing network operators to either immediately upgrade their software or disconnect entirely after AI-generated vulnerability reports submitted to their project proved to be entirely accurate.
These events unfolded against the backdrop of an already tense security environment. Earlier in the summer, the broader crypto ecosystem reeled from a Coldcard hardware wallet exploit executed on July 30, which saw attackers successfully drain 594 BTC in a span of just 25 minutes. Total losses across four distinct exploitation sweeps approached $114 million, underscoring the urgent need for open-source maintainers to adapt their defensive strategies.
By dismantling lengthy disclosure embargoes for easily reproducible bugs, Bitcoin Core aims to shorten the vulnerability lifecycle, ensuring that developers and node operators can patch critical weaknesses before automated tools can weaponize them against the network.
