What happened
On 22 October 2026, Bitcoin Core merged a change to its security policy for flaws that are easy to find again. The project now calls these vulnerabilities easily discoverable. A vulnerability is a software mistake that can let somebody crash, slow or otherwise misuse a program.
The policy gives one practical example: a flaw that a large language model can find with a simple prompt. The category is not limited to AI. Maintainers can use it whenever a report takes little effort to rediscover.
For those flaws, Bitcoin Core will copy the fix into every major version it still maintains. It will then publish point releases and a security advisory as soon as possible. A point release is a smaller update to an existing version rather than the next annual major release.
What it changes
The old policy used severity to decide how long details stayed private. Low-severity flaws were disclosed two weeks after a major release containing the fix. Medium and high flaws waited until two weeks after the last affected release reached end of life, usually about a year after the first fixed major version.
That delay protected people running old Bitcoin nodes only while attackers could not find the same bug. Developer Antoine Poinsot told the Bitcoin development mailing list that language models have lowered the effort needed to find some classes of issues and to spot quiet fixes in public code.
The new path changes that calculation. If rediscovery is already cheap, a long embargo leaves operators on vulnerable software without buying much secrecy. Backporting the fix means an operator can update a maintained version instead of waiting for the next major release.
It also changes the signal operators should watch. An important fix may now arrive in a point release with an advisory. Waiting only for the next major version could leave an easy-to-find flaw open longer.
What it does not change
No specific Bitcoin Core flaw was disclosed with this policy update. The change does not say that an AI system broke Bitcoin, that a new attack is active or that every AI-generated report is correct.
The ordinary timetable still applies when maintainers do not classify a flaw as easily discoverable. Critical bugs also remain outside the standard timetable and are handled case by case.
Speed has a cost. Poinsot wrote in the review that these fixes may have less time to mature in development branches before release. The maintainers debated whether an advisory could draw attention too early, but the final policy requires an advisory alongside the fixed releases.
A faster release does not update a node automatically. Bitcoin Core has no central switch that can force operators to install software. People running nodes still have to read the advisory, verify the release and decide when to upgrade.
Context
This is a follow-up to Bitcoin Core's 2024 disclosure policy, not a replacement for its severity scale. The new category creates an exception when waiting no longer gives defenders a useful head start.
Three independent newsrooms covered the merged change. CoinDesk reported the testing tradeoff and disagreement in the review. Decrypt explained why quiet fixes are harder to hide when automated tools can compare public code. Cointelegraph checked the change against the live policy and the development mailing list.
The reports agree on the new path: triage first, then backported fixes, point releases and an advisory. They do not establish how often maintainers will use the label or how many current reports fit it. The live policy sets no numeric threshold for "minimal effort", so classification remains a judgement during triage.