Bitcoin Core Security Policy Fast-Tracks Fixes for Easy-to-Find Bugs

Bitcoin Core has changed its security disclosure policy to accelerate fixes for vulnerabilities that large language models can find with little effort, ending the months-long embargoes those bugs once received. Maintainers merged the change to the project's security policy on Thursday, October 22.

The shift matters because Bitcoin Core runs on most nodes underpinning the network, making release timing consequential for operators who install updates. Under the new rule, node operators should receive fixes sooner for bugs that attackers can also find quickly with AI tools.

Why Maintainers Acted

Chaincode Labs developer Antoine Poinsot, who wrote the proposal, announced it in a message to the Bitcoin Development Mailing List the same day the change was merged. He said the project had seen a rise in reports of bugs that could be rediscovered with ease.

"We recently experienced an increase in the number of reports for security vulnerabilities that can be easily (re-)discovered," Poinsot wrote, adding that the trend is "largely due to LLMs drastically reducing the bar to find certain classes of issues or identify covert fixes." A covert fix is a patch that closes a hole without announcing it, and if a model can spot one, the secrecy around it no longer holds.

The change follows months of heightened pressure on Bitcoin's open-source projects. In late July, a volunteer group of 16 developers known as the Bitcoin Red Team ran AI models across 390 bitcoin repositories in about a day and logged 4,962 findings, including 85 rated critical. Within days, a BTCPay Server flaw the group had reported in private 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.

How the Old Embargo System Worked

Bitcoin Core has graded each reported vulnerability by severity and timed its disclosure to match. Low-severity flaws were made public two weeks after the next major version shipped, while medium- and high-severity issues stayed under embargo until two weeks after the last affected release reached end of life, a span that could stretch to a year.

The extended timelines gave node operators, many of whom upgrade at a slow pace, time to move to patched software before details became public. Poinsot referred to this as the project's slow upgrade culture. In practice, the approach meant fixes went unreleased for older maintained versions and arrived with the next major release.

Poinsot argued that this tradeoff fails for bugs that are easy to rediscover. An embargo protects users only while a bug stays secret, and if a short prompt to an AI model can surface the same bug, keeping it quiet until the next major release mostly leaves nodes running vulnerable code for longer.

"The embargo period achieves little but it delays the availability of a fixed release," the policy reads. "For these issues that are easy to find, this is the wrong tradeoff."

What the Bitcoin Core Security Policy Now Requires

During triage, Bitcoin Core can 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 is open to flaws found by other means as well, so the category is not limited to AI-discoverable bugs.

For those issues, the project will backport a fix to every maintained major version, cut point releases as soon as possible and publish a security advisory with some details at the same time as the fixed software. That marks a break from past practice, when fixes for older maintained versions often waited for a later major release. Poinsot acknowledged that such fixes will have less testing time before they reach users, a trade of some testing time for speed in this specific category.

The fast track does not mean Bitcoin Core will immediately publish details of every bug. Vulnerabilities outside that 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, remain outside the standard policy and will be handled case by case, most likely through an ad-hoc procedure.

Developer Antoine Riard, a longtime bitcoin security researcher, pushed for an option to ship a fix without an advisory and withhold details on a case-by-case basis. Poinsot declined, writing that "alerting users of a security vulnerability without any details could create more risk unnecessarily" by prompting "a rushed migration by users who would otherwise not be affected."

Severity Grades and Past Advisories

The project's policy page lays out the severity ladder that still governs most reports. Critical bugs threaten the fundamental security and integrity of the entire Bitcoin network, including a past flaw that allowed inflating the money supply by spending the same transaction output twice within a block (CVE-2018-17144) and a consensus failure that caused a network-wide chain split (BIP 50).

High-severity bugs have a significant impact on affected nodes or the network, such as a remotely triggerable crash that could take many nodes offline (CVE-2024-35202). Medium bugs noticeably degrade performance but are limited in scope or exploitability, while low-severity bugs are challenging to exploit or have minor impact, often only under non-default configurations.

The page also summarizes historical security advisories. A use-after-free in Bitcoin Core's script interpreter that let a specially crafted block remotely crash a node was fixed on October 10, 2025 in Bitcoin Core v30.0. Older entries include a fix released on June 3, 2020 in Bitcoin Core 0.20.0, another on September 14, 2017 in version 0.15.0, one on January 15, 2021 in version 0.21.0 and one on April 27, 2015 in version 0.10.1.

Reaction and Open Questions

The update drew support from at least one developer who has clashed with Poinsot before. "I've disagreed with Antoine's approach to security in the past, but this is a good update," developer Luke said, according to Cointelegraph.

Neither the mailing list post nor the policy page says how many easily rediscoverable reports Bitcoin Core has received, or whether any point releases have already shipped under the new rule. CoinDesk said no bug had yet been flagged under the new rule, according to the Bitcoin Foundation.

Bitcoin Core is not the only Bitcoin software team handling security pressure, with Lightning implementations and wallet projects also fielding AI-surfaced bug reports in recent months. All vulnerabilities should be reported to security@bitcoincore.org, according to the project's policy page.

Conclusion

Bitcoin Core's maintainers have merged a disclosure policy that strips long embargoes from vulnerabilities that large language models can rediscover with minimal effort, requiring backported fixes, prompt point releases and same-day advisories for that class of bug. Other flaws keep the severity-based schedule, and critical bugs remain a case-by-case matter. The next concrete step is the first application of the new label: no vulnerability has yet been flagged as easily discoverable under the rule, and the project has not said how many such reports it has received.

Frequently Asked Questions

What did Bitcoin Core change in its security policy on October 22, 2026?

Maintainers merged an update creating an "easily discoverable" category for vulnerabilities found with minimal effort, such as through a simple LLM prompt. Those bugs now get fixes backported to every maintained major version, point releases as soon as possible and a security advisory published alongside the patched software, instead of a long embargo.

Why did Antoine Poinsot propose ending embargoes for easy-to-find bugs?

Poinsot, a Chaincode Labs developer, wrote that the project saw an increase in reports of vulnerabilities that can be easily rediscovered, largely because LLMs lowered the bar to find certain issues or spot covert fixes. He argued an embargo achieves little for such bugs while delaying the availability of a fixed release.

How does the new Bitcoin Core policy treat critical and other vulnerabilities?

Vulnerabilities outside the easily discoverable category keep the existing severity-based schedule: low-severity flaws are disclosed two weeks after the next major version, while medium- and high-severity issues stay embargoed until two weeks after the last affected release reaches end of life. Critical bugs remain outside the standard policy and are handled case by case.

What AI-driven security events preceded the Bitcoin Core policy change?

In late July, a 16-developer volunteer group called the Bitcoin Red Team ran AI models across 390 bitcoin repositories in about a day, logging 4,962 findings including 85 rated critical. Days later, a privately reported BTCPay Server flaw was exploited on live merchant servers, draining Lightning nodes, and in August Core Lightning developers urged upgrades after accurate AI-generated reports.

Has any bug been flagged under Bitcoin Core's new easily discoverable rule?

No. CoinDesk said no bug had yet been flagged under the new rule, according to the Bitcoin Foundation. Neither Poinsot's mailing list post nor the policy page discloses how many easily rediscoverable reports Bitcoin Core has received or whether any point releases have shipped under the new process.