Bitcoin Core drops the embargo for bugs an LLM can find with a simple prompt

What Bitcoin Core changed

Bitcoin Core, the reference software most Bitcoin nodes run, has changed how it discloses security flaws because large language models now make some bugs trivial to find. A pull request to the project's website opened on 16 October 2026 by contributor Antoine Poinsot (darosior on GitHub) and merged on 22 October by maintainer fanquake adds a new category, the "easily discoverable" vulnerability, to the project's security advisories policy.

For flaws in that category, the project will no longer hold details back for months. It will publish a point release with the fix for every maintained major version "as soon as possible", along with a security advisory, skipping the usual severity-based embargo. The page says the label applies to vulnerabilities "that can be discovered with minimal effort, such as through a simple LLM prompt".

Poinsot also announced the change on the Bitcoin development mailing list, according to Cointelegraph. It is one of the clearest cases yet of a major open-source project rewriting its security process specifically because of AI-assisted bug hunting.

Why the old embargo existed

Bitcoin Core has long favoured secrecy. Under its existing policy, each reported bug is rated low, medium, high or critical. Low-severity bugs are disclosed two weeks after a major release that contains the fix. Medium and high bugs are disclosed only two weeks after the last affected release reaches end of life, roughly a year after the fix first shipped. Critical bugs, such as an inflation or coin theft bug, get an ad-hoc process.

The reason is the network's slow upgrade culture. Many people run old node versions for years, and a public write-up of a remote crash bug could be used against them. Keeping details quiet buys time. The cost, as Poinsot wrote in the pull request, is that fixes generally "can't be backported" to older versions, because a backport would reveal the bug. Users only get the fix when they move to the next major release.

Why LLMs broke the tradeoff

The pull request explains what changed. "We recently experienced an increase in the number of reports for security vulnerabilities that can be easily (re-)discovered," Poinsot wrote. "This is largely due to LLMs drastically reducing the bar to find certain classes of issues or identify covert fixes."

The second half of that sentence is the important part. Covert fixes are quiet patches that close a hole without saying so. Before, spotting one meant a skilled person reading diffs carefully. Now a model can be pointed at a stream of commits and asked which ones look like security fixes. If attackers can find the bug or the fix that easily, a long embargo protects nobody. "The embargo period achieves little but it delays the availability of a fixed release," Poinsot wrote.

The same pressure is visible across AI security research. AI Lookout has reported on Anthropic's claim that Claude proved 239 fuzz targets cannot crash and on its automated red-teamer beating human bug bounty hunters. Tools that help defenders also help anyone else with the same model.

What the new policy says

The new text slots into the existing policy rather than replacing it. During triage, maintainers decide whether a report is easily discoverable. If it is, the fix is backported to all maintained releases, a point release is cut as soon as possible, and a security advisory with "some details" goes out with the fixed binaries. If not, the old severity timelines still apply.

One wording change follows from that. The policy used to say a pre-announcement would be made two weeks before releasing details of "a vulnerability". It now says "an embargoed vulnerability", since easy-to-find bugs no longer wait for that cycle. Critical bugs remain outside the standard policy and are handled ad hoc.

The classification is a judgment call, not a test. The pull request says the maintainers "expect those to be issues that can be found with a simple prompt to an LLM", but that the label is not restricted to those. The policy does not say whether the team will actually run models against each report to decide.

How the maintainers argued it out

The review thread shows broad support with some real disagreement about the details. Several maintainers gave a quick "Concept ACK" within minutes of the pull request opening. Contributor stickies-v asked whether the project would still try to fix these bugs covertly and publish only once binaries were available, and suggested the policy should be rewritten rather than having a clause "bolted on at the end". Poinsot later blended the new rule into the existing paragraph.

Poinsot's answer on covert fixes was blunt: hiding such a patch "would achieve little" because the bug can already be found with a trivial scan and an aggressive backport would give it away anyway. He added that, because fixes will get less "bake time" in development branches, the team will more often accept giving up the remaining obscurity in exchange for a safer, better-tested patch.

Contributor sedited suggested that for some easy bugs the project could disclose mitigation steps, such as disabling a feature, even before a fixed release. Poinsot replied that warning users before a fix exists would usually do more harm than good below the critical level. Stickies-v noted that commitments to disclose only after a release "will be increasingly hard to hold" as the bar for what counts as easy keeps moving.

Part of a wider shift in open source

Bitcoin Core is not alone. Earlier this month the curl project moved in a similar direction, as AI Lookout reported when curl took low and medium vulnerability reports public to cope with an AI-driven flood of submissions. And the PHP project had to rush patches for the PHP2Shell flaws that AI helped researchers find.

Cointelegraph adds Bitcoin-specific context. It reports that in August the volunteer Bitcoin Red Team flagged nearly 5,000 potential issues across 390 projects, of which only about a fifth had been reproduced at the time, and that Core Lightning developers urged operators that month to upgrade or take nodes offline after multiple AI-generated vulnerability reports, while holding back details for two weeks. Those figures are the publication's; AI Lookout did not verify them independently.

The pattern across these projects is the same. Long embargoes assumed that finding a bug was hard and that secrecy bought time. When a model can rediscover the bug in minutes, the value of secrecy falls and the value of shipping a fix quickly rises.

What node operators should do

For people who run Bitcoin nodes, the change mainly means more frequent point releases for older supported versions, and less reason to wait for the next major version to get a security fix. Operators should watch the Bitcoin Core security advisories page and release announcements, and install point releases promptly, because an advisory for an easy bug may appear on the same day as the fix.

Anyone running a version that has already reached end of life will not get these backports at all. The project's lifecycle page lists which releases are still maintained. Businesses that build on Bitcoin Core, such as exchanges and custodians, may also want to shorten their own upgrade testing cycles, since the time between fix and public details is likely to shrink.

Open questions

The policy leaves several things open. It does not define how maintainers decide a bug is easily discoverable, how much detail an early advisory will contain, or how often point releases might be cut if reports keep rising. Contributor ariard, who proposed a separate accelerated process in the thread, argued after the merge that advisories should still withhold full exploitation details.

There is also a resource question. Backporting every easy fix to every maintained branch and cutting more releases is extra work for a volunteer-heavy project, at the same time as AI tools increase the number of reports to triage. Whether Bitcoin Core and projects like curl can keep up, or end up using the same models to triage reports faster, is the next thing to watch.