Bitcoin Core has changed its security-disclosure policy to deliver faster fixes for vulnerabilities that attackers can rediscover with little effort, including through a simple prompt to an AI language model.
The change was merged into the project’s website repository on October 22 and appears in the live security policy. Bugs classified as easily discoverable will receive point releases for every maintained major version as soon as possible, accompanied by a security advisory.
The decision concerns how future reports are handled. It does not announce a particular new Bitcoin vulnerability, a theft or a change to the network’s consensus rules.
An embargo has a cost as well as a benefit
Security disclosure involves a timing problem. Publishing details can help operators understand why to update, but it can also help attackers reproduce a flaw before those operators have installed the fix.
Delaying disclosure can provide time for coordinated preparation. That advantage becomes smaller when finding the same problem independently is cheap. A secret that is easy to rediscover may offer defenders less protection than expected.
In the pull-request discussion, developer Antoine Poinsot argued that long embargoes are the wrong trade-off for these cases because they delay fixed releases without providing much secrecy. The new category is based on discoverability, rather than being restricted to bugs found by one particular research tool.
The policy therefore changes the response to a class of reports. It does not assume that every finding produced by an AI system is valid or that all software vulnerabilities can be found through a short prompt.
Discoverability and severity answer different questions
Bitcoin Core continues to classify vulnerabilities by severity. That measures the potential consequences and conditions for exploitation. The easily discoverable classification separately considers how readily another party could identify the issue.
A flaw can be easy to find without being catastrophic. Conversely, a serious problem may require specialist knowledge or unusual conditions to reproduce. Operators need both pieces of information to assess a report rather than treating one label as a complete risk assessment.
For other vulnerabilities, the published policy retains severity-dependent schedules. Critical cases remain outside the standard process because they may require an individual response.
Maintained versions are the patch boundary
The commitment to point releases applies to maintained major versions. It should not be read as a promise that every historical Bitcoin Core release will receive a backported fix.
That distinction matters to operators who postpone upgrades for long periods. Knowing that a patch exists is different from running a supported version to which the project will supply it.
Our guide to keys, backups and recovery explains another part of operational security. Keeping control of keys and maintaining software are complementary responsibilities; neither substitutes for the other.
The immediate result is a more explicit route for shipping certain fixes quickly. The evidence to watch in an actual advisory will be the affected versions, the available patched releases and the conditions relevant to a particular deployment, rather than an assumption that the policy announcement itself means every node is vulnerable.