Bitcoin Core has officially overhauled its security disclosure policy to dramatically accelerate the deployment and distribution of patches for software vulnerabilities. The policy shift comes as the rise of large language models (LLMs) allows malicious actors and security researchers alike to uncover bugs with minimal effort, rendering traditional, months-long embargoes obsolete and potentially hazardous to the wider network.
Maintainers formally merged the modifications into the project’s security policy on Thursday. Antoine Poinsot, a developer at Chaincode Labs who authored the policy proposal, announced the critical change to the Bitcoin Development Mailing List on the very same day, signaling a major philosophical shift in how the backbone of the world’s leading cryptocurrency manages potential code weaknesses.
In his mailing list announcement, Poinsot highlighted the changing threat landscape that prompted the update. The project has recently experienced a noticeable uptick in reports detailing security vulnerabilities that can be effortlessly rediscovered or reverse-engineered from covert fixes. This acceleration, Poinsot explained, is largely driven by artificial intelligence models that have drastically lowered the barrier to entry for identifying specific classes of software issues or spotting patches before they are properly rolled out to the public.
How the Policy Worked Before
Bitcoin Core serves as the foundational software running on the vast majority of nodes across the decentralized Bitcoin network, making its security posture paramount to the ecosystem’s stability. Historically, the project evaluated every reported vulnerability on a strict grading scale based on its severity and timed its public disclosures accordingly. Under this legacy framework, low-severity flaws were kept under wraps until two weeks after the next major version of the software officially shipped.
Meanwhile, medium- and high-severity issues remained strictly embargoed until two weeks after the final affected release reached its end of life—a timeline that could easily stretch up to an entire calendar year.
The primary justification for these extended timelines was to provide node operators, many of whom historically upgrade their infrastructure at a cautious and deliberate pace, ample opportunity to transition to patched software before vulnerability details became public knowledge. In practice, however, this approach meant that critical fixes often went unreleased for older, still-maintained software versions, forcing users to wait until the arrival of the next major release cycle.
Poinsot argued in his proposal that this traditional tradeoff fundamentally fails when applied to bugs that can be easily found or replicated using modern automated tools. The policy document itself notes that an extended embargo period achieves little security value while actively delaying the availability of a properly fixed release, leaving users unnecessarily exposed to automated scanning and exploitation.
What Changes Under the New Framework
Under the newly adopted policy, the Bitcoin Core triage process gains the ability to formally flag a vulnerability as "easily discoverable." The policy explicitly defines this category as issues that can be uncovered with minimal effort, such as through a simple prompt directed at a large language model, though the label remains applicable to flaws discovered via other rapid means as well.
For vulnerabilities falling into this newly designated category, the project commits to a much more aggressive response timeline. Maintainers will backport a fix to every maintained major version of the software, cut point releases as rapidly as possible, and publish a security advisory containing technical details at the exact same time the fixed software is made available to the public.
Poinsot openly acknowledged that this expedited approach means such security patches will undergo significantly less testing time before reaching everyday users. Nevertheless, project maintainers determined that the speed of remediation outweighs the traditional buffer period when a bug is easily surfaced by automated systems.
Vulnerabilities that fall outside of this easily discoverable category will continue to follow the existing severity-based disclosure schedule. Furthermore, critical bugs capable of enabling protocol-level coin theft, inflating the Bitcoin supply, or triggering a permanent network chain split remain entirely outside the standard policy framework and will instead continue to be handled on a strict, case-by-case basis.
During the policy debate, developer Antoine Riard pushed for an option that would allow maintainers to ship fixes without an immediate advisory and withhold specific vulnerability details on a case-by-case basis. Poinsot ultimately declined the suggestion, writing that alerting users to an update without providing technical details could create unnecessary risk by prompting rushed migrations and panic among users who might not even be running affected configurations or versions.
A Summer of AI-Driven Reports
The swift policy change arrives on the heels of several months of heightened operational pressure on Bitcoin’s open-source ecosystem, driven largely by rapid advancements in artificial intelligence capabilities and automated auditing. In late July, a volunteer group consisting of 16 developers known as the Bitcoin Red Team deployed AI models across approximately 390 bitcoin-related repositories in roughly a single day. The automated audit logged an astonishing 4,962 findings, including 85 vulnerabilities rated as critical.
The real-world consequences of these AI-driven discoveries materialized almost immediately. Within days of the Red Team’s private disclosures, a flaw in BTCPay Server was exploited on live merchant servers, resulting in the draining of active Lightning network nodes.
By August, Core Lightning developers were compelled to issue urgent warnings advising node operators to upgrade their software immediately or disconnect entirely after AI-generated vulnerability reports submitted to the project proved to be entirely accurate.
These events followed closely on the heels of a high-profile hardware wallet exploit involving Coldcard devices. On July 30, attackers successfully drained 594 bitcoin in just 25 minutes. Across four separate attack sweeps, total losses approached $114 million, serving as a stark wake-up call to the broader cryptocurrency development community regarding the speed and scale at which modern exploits can be identified and executed.
