Bitcoin Core Ends Long Embargoes for Bugs AI Can Rediscover

Bitcoin Core has scrapped its months-long embargoes for vulnerabilities that large language models can rediscover with minimal effort, merging a security policy change that speeds up fixes for an entire class of AI-findable bugs. Maintainers approved the change on Thursday, and Antoine Poinsot, a developer at Chaincode Labs who wrote the proposal, announced it the same day on the Bitcoin Development Mailing List.

"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."

How did the old disclosure policy work?

Bitcoin Core, the software that runs on most nodes in the Bitcoin network, graded each reported vulnerability by severity and timed its disclosure to match. Low-severity flaws went public two weeks after the next major version shipped. Medium- and high-severity issues stayed under embargo until two weeks after the last affected release reached end of life — a window that could stretch to a full year.

Those long timelines existed for a practical reason: node operators, many of whom upgrade slowly, got time to move to patched software before details became public. In practice, the approach meant fixes went unreleased for older maintained versions and only arrived with the next major release.

Poinsot argued the tradeoff collapses for bugs that are trivial to rediscover. "The embargo period achieves little but it delays the availability of a fixed release," the policy text reads.

What changes under the new rules?

During triage, Bitcoin Core can now flag a vulnerability as "easily discoverable," a category the policy defines as issues that can be found "with minimal effort, such as through a simple LLM prompt." The label isn't limited to AI-found flaws — it's open to bugs surfaced by any other method.

For flagged issues, the project will:

• backport a fix to every maintained major version;
• cut point releases as soon as possible;
• publish a security advisory with some details at the same time the patched software ships.

Poinsot acknowledged the cost: these fixes will get less testing time before they reach users.

Vulnerabilities outside the new category keep the existing severity-based schedule. Critical bugs — those that could enable coin theft at the protocol level, inflate the supply or cause a permanent chain split — stay outside the standard policy and will be handled case by case.

One maintainer pushed back. Developer Antoine Riard wanted an option to ship a fix without an advisory and withhold details case by case. Poinsot declined, writing that alerting users without details "could create more risk unnecessarily" by prompting a rushed migration among users who would otherwise be unaffected.

Why is this happening now?

The change follows a summer of AI-driven pressure on Bitcoin's open-source ecosystem. In late July, a volunteer group of 16 developers called the Bitcoin Red Team ran AI models across 390 bitcoin repositories in roughly a day and logged 4,962 findings, including 85 rated critical.

Within days, a BTCPay Server flaw the group had reported privately was exploited on live merchant servers, draining Lightning nodes. In August, Core Lightning developers told operators to upgrade or disconnect after AI-generated reports to the project proved accurate.

The Red Team effort followed a Coldcard hardware wallet exploit in which attackers drained 594 BTC in 25 minutes on July 30. Losses across four sweeps approached $114 million.

Node operators should now expect faster point releases with concurrent advisories for easily discoverable flaws — and less lead time to schedule upgrades before vulnerability details go public.