Bitcoin Core says it is revising how it discloses security vulnerabilities, acknowledging that modern AI tools—especially large language models—can make certain flaws far easier to find and reproduce. In an email to the Bitcoin Development Mailing List, Bitcoin Core developer Antoine Poinsot argued that the traditional approach of keeping details secret for an extended embargo period no longer provides much added safety in some cases.
Under the updated policy, vulnerabilities judged “easily discoverable” will receive faster fixes across all maintained major versions, with security advisories released alongside the updates. Other bugs will still follow time-based schedules tied to severity and software release cycles.
Key takeaways
- Bitcoin Core is moving away from long disclosure embargoes for flaws that are “easily discoverable,” including issues that can be found with “a simple LLM prompt,” according to the updated policy.
- For the new category, fixes should be rolled out as soon as possible across all maintained major versions, with advisories published at the same time as the fix.
- Low-severity vulnerabilities will be disclosed two weeks after a fixed major version is released, while medium/high issues will be disclosed two weeks after the last affected release reaches end-of-life.
- Bitcoin Core indicates critical bugs are handled outside the standard policy, likely through an ad-hoc process.
Why Bitcoin Core is changing its disclosure approach
Historically, many open-source projects use disclosure embargoes: they keep vulnerability details private for a period to give users time to upgrade before the broader public learns what to look for. Poinsot told the Bitcoin Development Mailing List that this approach can delay the availability of a fixed release without providing meaningful protection when vulnerabilities are straightforward to rediscover.
In the email, Poinsot said that the embargo period “achieves little but it delays the availability of a fixed release,” adding that Bitcoin Core would therefore adjust its disclosure policy to account for this reality.
The underlying shift is tied to how security research is changing. Poinsot noted that AI-assisted discovery efforts can rapidly surface bugs, compressing the time between “unknown flaw” and “practically usable exploit path.” That environment changes the value of withholding details: if attackers can reproduce the issue quickly anyway, delayed disclosure may primarily postpone defensive updates rather than meaningfully reduce risk.
How the updated policy will work
Bitcoin Core’s updated security advisory policy, posted on its security advisories page, introduces a clear distinction between vulnerabilities that require traditional scheduling and those that don’t.
Under the new classification, “easily discoverable” vulnerabilities will be fixed promptly across all maintained major versions, and the corresponding security advisory will be published alongside the updates. Bitcoin Core explicitly describes this category as covering issues that can be found with minimal effort, including through a “simple LLM prompt.”
The policy also preserves disclosure timelines for other vulnerabilities based on severity and release lifecycle:
- Low-severity vulnerabilities: disclosed two weeks after the release of a major version containing the fix.
- Medium and high vulnerabilities: disclosed two weeks after the last affected release reaches “End of Life,” which is typically a year after the fix ships in the new major version.
Bitcoin Core also stated that critical bugs are not covered by the standard schedule, saying they would most likely require an ad-hoc procedure instead. This implies that the project expects the most dangerous issues to trigger a different operational response than routine patching and timed advisory publication.
What this means for users running older releases
One of the most consequential practical implications of disclosure timing is upgrade pressure—especially for systems not updated immediately. Bitcoin Core previously reflected an approach in which secrecy around vulnerability details could limit how quickly fixes were backported, leaving users to wait until the next major release cycle for relief. Poinsot’s argument focuses on removing that friction when AI tools reduce the protective value of secrecy.
By prioritizing prompt backporting for “easily discoverable” issues, Bitcoin Core is effectively trying to shorten the window in which operators remain exposed due to their version staying on older release lines. For node operators, wallet integrators, and any downstream systems dependent on Bitcoin Core releases, the update underscores that “waiting for the next major version” may be less defensible for some bug classes.
That said, the policy change is not an across-the-board move to immediate disclosure for every vulnerability. Bitcoin Core’s distinction by severity suggests that it still intends to balance transparency and operational readiness, with the biggest acceleration reserved for cases where the difficulty of finding the flaw is already low.
The broader context: AI security research is pressuring the whole stack
The timing of Bitcoin Core’s policy update aligns with increasing reports of AI-generated vulnerability discovery across the Bitcoin ecosystem. In August, the volunteer Bitcoin Red Team reported nearly 5,000 potential issues across 390 projects, noting that only about a fifth of its findings had been reproduced at the time. Other development circles responded to AI-driven reports by urging operators to upgrade or even take nodes offline while waiting for verified remediation.
Cointelegraph previously reported that Core Lightning developers urged operators to upgrade or take nodes offline after multiple AI-generated vulnerability reports, while another coverage highlighted instances where technical details were withheld for two weeks. Although those stories refer to different software components and disclosure decisions, they reflect a shared tension: when AI tooling rapidly produces plausible vulnerabilities, developers must decide how to prevent premature disclosure from causing panic or unnecessary disruption—without letting the defensive timeline drag.
Bitcoin Core’s revised stance indicates it believes that, for certain bug types, the equilibrium has shifted. If adversaries can quickly find the same weaknesses using widely available tools, delaying fixes becomes a bigger liability than publishing details immediately with patches.
Looking ahead: watch how “easily discoverable” is applied
Bitcoin Core’s policy introduces a category that depends on practical classification—what counts as “easily discoverable” and how consistently that standard is applied. The next advisories released under the updated approach will be the clearest test of how the project operationalizes the rule and how quickly maintained versions receive synchronized fixes.
