Bitcoin Core Updates Security Policy for AI-Assisted Bug Hunting
Key Takeaways
- •Bitcoin Core approved a policy revision under which easily discoverable vulnerabilities are patched and disclosed immediately, skipping the customary embargo period.
- •Developer Antoine Poinsot announced the change on the Bitcoin Development Mailing List on October 22, 2026, with the category exemplified by flaws that simple LLM prompts can surface.
- •The revision responds to an uptick in AI-related vulnerability reports, based on the conclusion that embargoes provide little benefit for flaws that can be readily rediscovered.
- •Disclosure timelines for other severities remain unchanged, with low-severity issues disclosed two weeks after a major release, medium- and high-severity issues waiting until two weeks after the last affected release reaches end of life, and critical issues still handled ad hoc.
- •Fixes in the new category will be backported to every actively supported major version, though no real vulnerability has yet been placed in the category.

Bitcoin Core, the reference implementation of the Bitcoin protocol, has approved a revision to its vulnerability disclosure policy: bugs simple enough to be found with minimal effort will now be patched and disclosed immediately, skipping the embargo period that ordinarily separates a fix from public disclosure.
What changed in the disclosure rules
Developer Antoine Poinsot announced the revision on October 22, 2026, in a discussion on the Bitcoin Development Mailing List. The update introduces a new vulnerability category labeled "easily discoverable," covering flaws that can be identified with little effort. The headline example is anything that surfaces from simple prompts aimed at large language models (LLMs), the technology behind modern AI chatbots.
Bugs falling into this bucket receive treatment different from everything else: fixes will be backported immediately to every actively supported major version of Bitcoin Core, and a security advisory will be published at the same time.
The rest of the policy stays in place. Low-severity vulnerabilities are still disclosed two weeks after a major release. Medium- and high-severity vulnerabilities continue to wait until two weeks after the last affected release reaches end of life — a window that typically works out to about a year after the fix. Critical vulnerabilities remain outside the new framework entirely and will continue to be handled on an ad hoc basis.
Those waiting periods are a fixture of coordinated vulnerability disclosure across the software industry: a fix ships first, and public details follow once users have had time to update, limiting how widely a flaw is known before patches are in place.
Why AI forced the issue
The change responds to an uptick in vulnerability reports linked to the growing use of AI tools, which have made certain kinds of issues easier to unearth and easier to reproduce.
The Bitcoin Core team acknowledged the trade-offs involved. On one side is transparency; on the other is the urgency of getting users to upgrade. For flaws that are easy to find again, the team concluded that lengthy embargoes were not delivering a meaningful benefit.
The rationale follows from the technology itself: an embargo only buys protection while a flaw stays hard to find, and a bug that a chatbot can surface from a simple prompt is one that can be found again at any time.
Two details stand out. First, no vulnerabilities have yet been placed in the new category, so the policy has not actually been applied to a real bug. Second, the category is not limited to AI-discovered issues: the definition hinges on how easy a flaw is to find, not on tool found it.
What this means for node operators
The most direct effect falls on people running Bitcoin Core nodes. When an easily discoverable bug is found, they may see a patch and an advisory arrive together, with no grace period before the details are public. That collapses the gap between a fix becoming available and the flaw behind it becoming common knowledge.
The backport commitment matters here. Because fixes go to all actively supported major versions, operators who are not on the latest release still receive a patch without having to jump to a new major version.
The open questions are practical ones. How will the team decide what counts as "easily discoverable," and how consistently will that line be drawn once real reports start landing? The first bug placed in the category will offer the clearest answer.