Bitcoin Core Tightens Its Rules as AI Uncovers Vulnerabilities

Bitcoin Core changes its way of handling certain vulnerabilities because of artificial intelligence. Developers now acknowledge that a bug can be so easy to find that a simple prompt sent to an AI model is sometimes enough. In this case, keeping the flaw secret for several months no longer really protects users. Bitcoin Core prefers to fix faster and publish the security notice at the same time. No new critical Bitcoin bug is announced. It is the defense policy that evolves.

Bitcoin Core changes its rules facing AI

The change was announced by Antoine Poinsot, Bitcoin Core developer. It adds a new category to the security policy: “easily discoverable” vulnerabilities. The decision comes a few days after the release of Bitcoin Core 32.0, already audited with the help of AI models.

The principle is quite simple. When a flaw belongs to this new category, developers will no longer necessarily wait for the next major Bitcoin Core release. The fix could be backported to all still officially supported major versions.

Intermediate versions can then be released quickly. The security notice will appear at the same time. Bitcoin Core defines as easily discoverable a vulnerability that can be identified with minimal effort, for example using a simple prompt sent to a large language model.

AI is only an example, however. A vulnerability obvious for other reasons can also enter this category. The classification is still decided by developers when they analyze the problem. This nuance matters: Bitcoin Core does not create a special category called “bugs found by ChatGPT.” The project mainly adapts its policy to the actual difficulty level required to find a flaw. And this level has just dropped.

Long embargoes protected better before LLMs

Traditional vulnerability management relies largely on temporary secrecy. A researcher discovers a problem. They discreetly communicate it to developers. They prepare a fix and include it in a new version without necessarily immediately explaining the risk.

Details come later. This method gives users time to update their software before attackers have a complete manual.

Bitcoin Core operates with a fairly precise disclosure schedule. A low-severity vulnerability can be made public two weeks after the major version containing its fix is released. For medium or high-severity problems, the wait can be much longer. The publication normally occurs two weeks after the last affected version reaches end-of-life.

In some cases, this represents about a year. Critical bugs follow a different procedure. Bitcoin Core notably places in this category problems potentially allowing the creation of bitcoins outside the planned monetary schedule, theft of BTC at the protocol level, or a permanent network split.

These vulnerabilities remain exceptional cases. The arrival of LLMs mainly changes the reasoning for bugs less difficult to reconstruct. Bitcoin Core’s code is public. Changes to the software are also public. An outside developer can therefore compare two versions and look for why some lines suddenly changed.

Before AI, this operation could require significant skills and several hours or days. Now, part of the work can be automated. A model can read the change, examine the affected functions, and propose an explanation of the fixed vulnerability.

Nearly 5,000 Bitcoin bugs reported in 27 hours

The change is not theoretical. In early August, the Bitcoin Red Team showed the scale that vulnerability research could take when powered by AI. In 27.5 hours, sixteen developers had produced 4,962 reports across 390 Bitcoin-related projects.

Among those were 85 problems classified as critical and 635 as high severity. This does not mean Bitcoin suddenly had 85 exploitable critical flaws. Most of these reports still had to be reproduced and checked by humans. AI can misunderstand code, invent an exploitation condition, or consider as vulnerable a perfectly intended behavior.

At the first assessment, only a part of the thousands of results had been confirmed. The volume remains unusual. Security teams can now run several models simultaneously on hundreds of repositories and get thousands of leads within hours.

The problem then shifts to filtering. The bug must be reproduced, affected versions determined, impact measured, a fix prepared, and verification that the fix does not create another problem. Bitcoin Core encountered this phenomenon directly in 2026. During preparation of version 32.0, contributor Matthew Zipkin used Kimi K3 to review the new HTTP server. The model identified a scenario where certain requests could cause excessive memory consumption.

Developers then continued manually. The bug was real, but human analysis showed its scope exceeded the first AI diagnosis. It’s probably a good image of the current situation: the model quickly finds a lead, then developers must understand what it really means. AI speeds up the first step. It does not eliminate the next ones.

Lightning and wallets have already received the warning

Bitcoin Core is only part of the Bitcoin ecosystem. Millions of dollars can depend on a wallet, a Lightning node, a payment processor, or a software library without a flaw directly affecting the Bitcoin protocol.

The summer of 2026 provided several examples. Core Lightning received a series of reports generated with AI models’ help. Several vulnerabilities proved serious enough to push developers to ask operators to immediately update their software.

Those who could not install the fix quickly were even asked to disconnect their nodes’ communications. Technical details had been embargoed for two weeks. This is exactly the kind of situation that becomes more delicate if another model can find the vulnerability before that period ends.

Coldcard had another experience. After a theft exceeding $114 million linked to a weak random generation, the manufacturer used several AI models to search for other vulnerabilities.

The analyses identified additional problems in transaction management, USB exchanges, and the update mechanism.

Again, AI did not replace human audit. It significantly increased the amount of code that could be examined. This capacity obviously works both ways. A company can use a model to secure its wallet. An attacker can send the same GitHub repository to a comparable model and ask where the errors are. Open-source software does not become less safe because of that. But the speed at which its flaws can be explored increases.

Bitcoin must now fix before AI rediscovers

For Bitcoin node operators, the change should mainly make intermediate versions more important. A minor update can now include a fix for a vulnerability easy enough to find for Bitcoin Core to refuse to wait for the next major release.

Users who remain long on old versions take greater risks. Bitcoin Core does not maintain all its versions indefinitely. Once a branch reaches end-of-life, it generally no longer receives new fixes.

The arrival of AI thus reinforces advice that already existed: keep software in the Bitcoin ecosystem up to date. It also changes how to measure the danger of a bug. For a long time, a vulnerability could remain hidden for years simply because no human took the time to carefully examine the few lines involved.

This reasoning becomes less reassuring. A better model may appear six months later and analyze in minutes code untouched for five years.

This does not mean at all that AI can “break Bitcoin.” It cannot guess private keys, break SHA-256, or arbitrarily change the 21 million BTC limit. Warnings about AI and Bitcoin nowadays mainly concern software, much more than cryptographic primitives themselves. The difference is important.

A network can have strong cryptography while retaining errors in an HTTP server, a wallet, a library, or a Lightning Network implementation. LLMs excel increasingly in reviewing this kind of code. Bitcoin Core therefore adapts its defense to a rather new situation: a vulnerability can be officially secret while technically easy to find.