← Blog

Bitcoin Core ends bug secrecy for flaws an AI chatbot can find with one prompt

Developers merged the policy change this week after a surge in reports of easily found bugs, and no vulnerability has been classified under it yet.

24 October 2026 • 7 min read

Bitcoin Core ends bug secrecy for flaws an AI chatbot can find with one prompt

Until this week, a medium or high-severity bug in Bitcoin Core could stay secret for around a year after its fix had quietly shipped. Under the old schedule, low-severity flaws were revealed two weeks after the next major version shipped, while medium and high ones stayed under embargo until two weeks after the last affected version reached end of life. CoinDesk reports that the new rules replace embargoes that could last about a year for one class of bug: the kind a chatbot can find.

Maintainers merged the change on Thursday, October 22. A secret only protects anyone while it stays secret, and a large language model can now rediscover some bugs on request, so for those flaws Bitcoin Core will ship fixes and tell the public at once. That puts the job of staying safe on node operators, who now have to update fast.

What the new label changes

Antoine Poinsot, a Chaincode Labs developer, wrote the proposal. According to Unchained, he opened the proposal on Oct. 16, and it was approved by several contributors and merged by Michael "fanquake" Ford. In an Oct. 22 message to the Bitcoin Development Mailing List, quoted by Bitcoin.com, Poinsot wrote: "We recently experienced an increase in the number of reports for security vulnerabilities that can be easily (re-)discovered."

At its center is a new triage label. The policy text, as Cointelegraph quotes it, says "This classification applies to vulnerabilities that can be discovered with minimal effort, such as through a simple LLM prompt." The label turns on how easy a bug is to find, whoever happens to find it, and the pull request says so directly: "In practice, we expect those to be issues that can be found with a simple prompt to an LLM, but the classification is not restricted to those."

Once a bug gets the label, the old waiting period goes away. Bitcoin Core will backport a fix to every maintained major version, issue point releases as soon as possible and publish a security advisory with some details alongside the patched software. Under the old system, fixes were not released for older maintained versions and instead appeared in the following major release.

Bugs that don't qualify remain on the existing severity-based disclosure schedule. Critical bugs remain outside the standard policy and will be handled case by case; the project's examples include flaws that could enable coin theft at the protocol level, inflate the supply or cause a permanent chain split. Analytics Insight points out that the change concerns security updates, not Bitcoin's transaction rules.

Why secrecy stopped working

Behind the old embargo sat an assumption that attackers would struggle to find a bug and would also miss the quiet fix that closed it. Poinsot argued that both assumptions have broken down. Decrypt reports he wrote that language models have "drastically reduced the bar" to find certain classes of issues or to spot a quietly shipped fix in the code. In Unchained's account, Poinsot told the discussion that covertly patching such a bug "would achieve little," since a trivial LLM scan can find it and an aggressive backport gives it away anyway. In his email, quoted by Cointelegraph, he said: "The embargo period achieves little but it delays the availability of a fixed release."

Bug reports kept the bitcoin ecosystem busy over the summer. CoinDesk reports that the policy follows a review of 390 Bitcoin projects that identified 4,962 potential flaws, 85 of them critical. Crypto Intelligence says a volunteer group called the Bitcoin Red Team, made up of 16 developers, pointed AI models at roughly 390 Bitcoin-related projects. Crypto Briefing and TFTC put that 27.5-hour audit on August 4 to 5, 2026, and Bitcoin Magazine reports it was triggered by the Coldcard exploit. TFTC reported that only about a fifth of the findings (21.4%) had been independently reproduced at the time. Then, in August, developers of Core Lightning, a major implementation of the Lightning Network, urged node operators to upgrade or take their machines offline after receiving a burst of AI-generated vulnerability reports.

Outside crypto, this week also showed how fast a public bug can turn into an attack. Two critical PHP flaws (CVE-2026-109618 and CVE-2026-109619, rated 9.2) were patched on October 21. Cloudflare CEO Matthew Prince wrote that in "the 10 hours before it was publicly announced, across the network we saw thousands of attempts to exploit it. That jumped to tens of thousands in the 45 minutes post announcement, hundreds of thousands within 2 hours, and millions now". Cybernews reported that Amazon detected PHP2Shell attack attempts on October 17th, before the flaw became public. According to Cryptonews, the PHP Foundation said a 2024 audit first surfaced one of the flaws and that work on a fix stalled for months. PHP is a different project with different disclosure rules, but its week contained both things Bitcoin Core is planning around: a secret that leaked anyway, and a flood of attacks once details went public.

The cost lands on whoever runs the node

Developers on the project admit the trade-off. Poinsot acknowledged that the accelerated fixes will undergo less testing before users receive them.

Not everyone agreed. Longtime bitcoin security researcher Antoine Riard argued that Bitcoin Core should retain discretion to release fixes without advisories and withhold details case by case. Poinsot rejected that proposal, saying warnings without details could unnecessarily increase risk by encouraging unaffected users to migrate hastily. Another contributor, Stéphan Vuylsteke, pushed the other way and suggested disclosing these bugs no later than when the fix's pull request opens. Poinsot held the middle ground: for less than critical bugs, warning users before a fixed version exists would likely do more harm than good.

No vulnerability has been placed in the new category yet, so the policy is untested in the real world. No live flaw has been reported, and the change doesn't suggest bitcoin is unsafe.

Some changes are coming, though, for anyone running Bitcoin Core directly or relying on a service built on it, such as an exchange, custodian or wallet backend. Every advisory under the new label will arrive together with a patch, and anyone reading it, attackers included, gets a map to unpatched nodes. The PHP numbers show how quickly such a map gets used.

If you run a node, stay on a maintained major version, since those are the ones that get backports, and treat any point release that comes with an advisory as urgent. If you hold coins with a custodian, you can't install anything yourself, but you can ask how quickly they apply Bitcoin Core security releases.

Sources