Bitcoin Core fixes its first AI-found bugs under the fast-disclosure rule: a peer could crash Windows and Mac nodes

The Bitcoin Core project published three security advisories on Wednesday 28 October 2026, the first released under the “easily discoverable” rule the project added to its security policy six days earlier. All three bugs were found by Project Loupe, an automated vulnerability scan driven by a large language model and run by Spiral, the open-source Bitcoin unit of Block. The fixes ship in four releases at once: 29.5, 30.4, 31.2 and 32.1.

The most serious Bitcoin Core vulnerability of the three, rated Medium, lets a malicious peer exhaust the memory of a node running on Windows, macOS or BSD until the program crashes. Linux nodes are not affected by that one. According to the advisory on bitcoincore.org, such a peer can “trivially crash” any Windows, macOS or BSD node it is connected to.

No coins are at risk. The bugs can stop a node, they cannot move or steal anyone’s bitcoin, and none of the advisories or the outlets that covered them, CoinDesk and Journal du Coin among them, reports any exploitation so far. The people who need to act are those who run a node: hobbyists, businesses and services that keep their own copy of the blockchain. Someone who simply holds bitcoin on an exchange or in a wallet app has nothing to do.

The rule itself, merged on 22 October, is explained in our report on Bitcoin Core dropping its year-long embargo for AI-findable bugs. In short: when a bug is judged easy to find, for example by prompting a language model, the fix is backported to every maintained version and the advisory goes out with the releases, without the usual waiting period. This week is the first time it has been used.

TCP urgent data: the Bitcoin Core vulnerability that crashes Windows, macOS and BSD nodes

The headline bug sits in the code that reads data from peers. Bitcoin Core watches its network connections with a function called poll() on Linux and an older one, select(), on other systems. Only the select() path was affected, which is why Linux machines are spared.

When a peer sends data faster than the node can process it, Bitcoin Core pauses reading from that peer. It is a form of backpressure, and each peer has a limit on how much data can wait in its queue. The flaw: on the select() path, the node kept watching paused sockets for “exceptional conditions”. A peer could trigger one by sending TCP urgent data, also called out-of-band data, a rarely used feature of the internet’s transport protocol. Handling that event made the node read anyway, and the data read that way was queued without any limit.

Repeat the trick and the queue grows until the computer runs out of memory. Bitcoin Core rates the bug Medium and flags it “easily discoverable”. The advisory gives no explicit range of affected versions and, like the other two, lists no CVE identifier.

Loupe flagged the problem on 23 October. Gregory Sanders, a Bitcoin Core contributor, validated it and alerted the project’s security team the same day. Antoine Poinsot wrote the fix, pull request #36665, which was opened, merged and backported on 26 October. Releases 31.2 and 32.1 followed on 27 October, and 29.5 and 30.4 on 28 October, together with the public advisory.

Two slower bugs: memory creep from paused peers and an undo file that wraps past 4 GiB

A queue that grows by megabytes per hour

The second Medium bug, described in a separate advisory on paused pre-BIP31 peers, also ends in memory exhaustion, only much more slowly. When a peer reads too slowly, Bitcoin Core marks it as paused for sending, yet it keeps adding some announcements to that peer’s outgoing queue, above all the frequent announcements of new transactions. Normally a peer that does not answer a ping within 20 minutes gets disconnected. But a peer that claims not to support BIP 31, the protocol change that put a random nonce in pings and added a matching “pong” reply, is not cut off for failing to answer. A malicious peer can therefore declare itself old, read slowly on purpose, and let its queue swell.

The advisory puts a figure on it: “Memory usage could grow at a rate of up to 2MB per hour per inbound peer, and 5MB per hour per outbound peer.” Nodes started with the -blocksonly option, which do not relay transactions, are much less affected, since transaction announcements make up the bulk of the queue.

Loupe reported this one to Sanders on 15 September, and he notified the security team that day. On 21 September a developer known as L0rinc found it independently and told Sanders privately, only to learn it was already reported. The fix, pull request #36667, was merged and backported on 26 October.

Undo files, reorgs and a 32-bit counter

The third bug, rated Low, is about storage. A node keeps “undo data” in files named rev*.dat: the information it needs to roll back a block if the chain reorganises and a block is replaced. Those files had no size limit, and positions inside them were stored as 32-bit numbers.

According to the undo file advisory, a miner could publish valid blocks carrying enough undo data to push a single file past 4 GiB. The position counter then wraps around and newer data overwrites older data. If a reorg later disconnects the affected block, the node shuts down, and restarting does not help: recovery needs a -reindex with a fixed version. On Windows and on 32-bit systems the limit is 2 GiB, the node fails to write undo data beyond it and shuts down on every restart. That variant needs about half the data and no reorg at all.

The advisory calls exploitation on 64-bit systems impractical. An attacker would have to mine several thousand blocks of nonstandard transactions, roughly a month of the whole network’s block production. About 18 more of its blocks would then have to land at the very end of one block file on the targeted nodes, and it would have to win a two-block reorg. Block file layouts differ from node to node, so no single placement works everywhere. The page also mentions a theoretical path to corrupting a node’s set of unspent outputs (the UTXO set), which would require even more control over the files.

Loupe reported this bug first, on 8 July. L0rinc found it independently on 21 August and Andrew Dorman on 23 October. Poinsot’s fix, pull request #36669, was merged on 26 October with one backport for each maintained line: #36658 for 32.x, #36661 for 31.x, #36664 for 30.x and #36666 for 29.x. Block and undo file positions are now stored as 64-bit numbers, and Windows builds use 64-bit file positioning. The on-disk format does not change.

From report to public advisory in five days

The first bug is the cleanest test of the new rule. It went from an automated flag to a public advisory in five days. The table sets out the three timelines as the advisories give them.

Under the old regime, a Medium or High bug could stay under embargo for up to a year after the fix. The best known recent case is CVE-2024-52911, a high-severity remote crash in the script interpreter: it was fixed in version 29.0 in April 2025 and only made public in May 2026. In October 2025, four Low-severity advisories fixed in 30.0 were published with CVE numbers under the same older process. Poinsot’s argument for the change, in his email to the bitcoin-dev list, was blunt: “The embargo period achieves little but it delays the availability of a fixed release.”

The two older reports raise a question the advisories do not answer. Loupe flagged the undo bug in July and the memory creep in September, yet both fixes landed on the same day as the five-day bug, 26 October. The pages give the dates but not the reason for the gap.

Who found the bugs: Spiral’s Project Loupe

Spiral launched Loupe on 12 May 2026, presented by Elias Rohrer, Jordan Mecom and Thomas Kilbride. It is offered free as “scanning-as-a-service” to open-source Bitcoin projects. Its first tests covered Bitcoin Core, BDK, LDK, rust-bitcoin, Cashu, Blockstream Jade, bitcoinj and the Stratum Reference Implementation. Projects bring their own access to a model, and Spiral and Block pay for the scans they run themselves. Spiral describes the tool as model-agnostic and does not say which AI model or vendor it uses.

Spiral says Loupe “will only report vulnerabilities backed by a demonstrable test case”. In this batch a human checked every finding before it reached the security team: Sanders validated all three, according to the advisories and to coverage by CoinDesk and Journal du Coin. The credits name Rohrer for Loupe. Spiral’s stated long-term goal is to hand the scanning over to each project’s own maintainers.

The independent rediscoveries matter as much as the scan. Two of the three bugs were found again by humans, L0rinc twice and Dorman once, which is the case the “easily discoverable” label was written for: bugs that other people, or other scans, are likely to find on their own while an embargo runs.

These advisories are part of a wider run of AI-assisted bug finding in Bitcoin software since August. They are unrelated to the two bitcoinjs-lib flaws reported this week, which concern bitcoinjs-lib, a JavaScript library and a different piece of software from Bitcoin Core; see our report on the bitcoinjs-lib fee bugs.

What node operators on Windows, macOS and BSD should do now

The advice in the advisories and in the 32.1 release announcement is short. It applies to anyone who runs Bitcoin Core, with the urgency highest on non-Linux machines.

• Windows, macOS and BSD nodes should move to the fixed release of their branch: 29.5, 30.4, 31.2 or 32.1.
• Linux nodes are not exposed to the TCP urgent data bug, but the other two advisories apply to every platform, so an upgrade is still the remedy.
• To upgrade, shut the old version down completely, then install the new one over it, as the 32.1 announcement describes.
• A node that has already stopped because of the undo file bug will not recover by restarting: it needs to run with -reindex on a fixed version.
• Download only from bitcoincore.org and verify the release signatures before installing.

Which release to pick, and why 32.0 is skipped

Version 32.0 was tagged but, in the words of the 32.1 release announcement posted by fanquake on the developers’ forum, “never fully announced or released” because of last-minute issues, so 32.1 is the release to use for that line. It also fixes a separate wallet issue: on non-Windows systems, an authenticated RPC caller allowed to create wallets could run commands when the -walletnotify option was set; wallet names are now treated literally. The announcement lists minimum platforms of Linux kernel 3.17, macOS 14 and Windows 10 (version 1903), and says the next major version plans to drop builds made with Microsoft’s MSVC compiler.

Operators on 29.x got a fixed release this week. How long that line keeps receiving fixes is a separate question: the 32.1 post and the project’s lifecycle page do not word it the same way, and this article makes no claim on it.

Still exposed after the fix: 32-bit machines, FAT32 drives and end-of-life nodes

Upgrading does not close everything. The undo file bug stays exploitable, at Low severity, on 32-bit systems and on nodes that store their blocks on a FAT32 drive, a file system that caps any single file at 4 GiB. The advisory names both cases. For the slow memory bug, -blocksonly reduces the exposure.

The larger gap is old software. Only maintained lines get backported fixes, and a large share of the public network does not run one. In a crawl by the Karlsruhe Institute of Technology (KIT) on 18 October, counting 9,691 reachable IPv4 and IPv6 peers, Coindaro found 8,418 plain Bitcoin Core user agents, split as follows (detail in our count of Bitcoin Core nodes on end-of-life versions).

For the 3,742 nodes on 28.x or older, no patch exists. On Windows, macOS or BSD, the only protection against the TCP bug is to move to a maintained version, or to a Linux host. The sample leaves out Tor-only nodes, nodes that do not accept incoming connections and private company infrastructure, and versions are self-reported.

Two figures are not known, and Coindaro does not estimate them. No source gives the share of nodes running on Windows, macOS or BSD: node trackers record user agents, not operating systems. And the share already on the fixed releases is close to zero by definition, since they are one or two days old. The btcnodes.io snapshot fetched on 29 October counted 18,092 validated nodes, but we could not extract a version split from it.

Why a node crash is not a theft

A Bitcoin node checks every block and transaction against the rules and relays them to its peers. If it crashes, it stops doing that until someone restarts it, as Journal du Coin pointed out; the coins recorded on the blockchain do not move. The risk for a business is downtime: a payment processor or exchange whose own node falls over cannot see new transactions until it is back. Our guide to where crypto hacks really happen explains why attacks on the software around a blockchain differ from attacks on the chain itself.

The severity labels follow Bitcoin Core’s own scale. The TCP bug is Medium even though the crash is easy to cause; the advisory does not spell out the reasoning behind the rating, and none of the three pages links the bugs to any loss of funds.

Next date: three more advisories due around 11 November

The flow is not over. The 32.1 announcement says disclosure of other fixes follows the policy, and that three Medium or High severity issues fixed in version 30.0 will be disclosed “in two weeks”, which CoinDesk reads as around 11 November. Those fall under the ordinary embargo rules, not the fast lane.

Several points remain open: CVE identifiers for this week’s three advisories (none is listed on the pages so far, while earlier advisories on the same index carry one), an explicit range of affected versions, and the share of nodes that will upgrade.