Bitcoin Core Publishes Three AI-Found Bugs, Including a Trivial Crash for Windows and Mac Nodes

Bitcoin Core published three security advisories on 28 October 2026, and the way they arrived matters as much as what they contained. All three were found by an automated scan that used a large language model to comb through the code. None was kept secret for a year while users quietly upgraded, which is how the project has handled most serious flaws in the past.

Two of the bugs are rated Medium and one Low. Together they describe a node that can be knocked offline by a stranger, a node that can be made to leak memory for hours, and a file-format flaw that is theoretically severe and practically almost impossible to trigger. Fixes went out in Bitcoin Core 29.5, 30.4, 31.2 and 32.1 across 27 and 28 October.

What was actually disclosed

The three advisories carry plain descriptions rather than CVE-style jargon: unbounded memory growth through TCP urgent data on non-Linux systems; slow unbounded memory growth on paused pre-BIP31 peers; and undo file overflow under extreme conditions. Every one is labelled “easily discoverable”, the classification Bitcoin Core introduced six days earlier.

The attribution is unusually specific. All three came out of Project Loupe, a free vulnerability scanner for open-source Bitcoin projects that Spiral and Block launched in May, with Bitcoin Core among its first test subjects. Elias Rohrer leads the work at Spiral. Developer Gregory Sanders validated each finding and passed it to the project's security team, which is what turned a machine-generated report into an accepted bug.

The repair work was fast by any standard. Antoine Poinsot opened pull requests 36665, 36667 and 36669 on 26 October, all three were merged and backported to the 29, 30, 31 and 32 branches the same day, and point releases followed within 48 hours.

Why a node crash is a bigger deal than it sounds

A Bitcoin node checks every transaction and block against the rules, keeps a copy of the chain, and passes data on to other nodes. It is the part of Bitcoin that does not depend on trusting anybody. Crash one and you have not lost coins, but you have lost a validator and a relay, and if enough go down the network gets thinner and slower.

That distinction separates this week's news from the kind that should make holders nervous. None of the three bugs breaks consensus, creates coins outside the schedule, or exposes private keys. They are availability problems, not custody problems. The advisory language is blunt all the same: a malicious peer could “trivially crash any Windows, macOS or BSD node it is connected to.”

How a stranger could crash a Windows or Mac node

The first bug comes down to which system call the software uses to watch its network sockets. On Linux, Bitcoin Core uses poll(). Elsewhere it falls back to a select()-based backend, and that path had a hole.

Bitcoin Core limits how much data it will queue for a peer, pausing reads when the queue gets too large. But the select() backend also watched sockets for “exceptional conditions” — out-of-band events — regardless of whether reads had been paused. When that event fired, the node read from the socket anyway, adding data to the queue of a peer it had already stopped reading from. TCP urgent data triggers exactly that event, so a paused peer could keep piling data up without limit until the machine ran out of memory.

Loupe flagged this on 23 October, Sanders confirmed it the same day, and the fix was merged three days later. Linux operators were never exposed, which covers most of the network but not the desktop wallets, hobbyist machines and small businesses running the software on a Mac or a Windows box.

The slow leak that needed patience

The second Medium bug is the opposite of the first: no clever packet, just a queue that never stops growing. Bitcoin Core pauses peers that read too slowly, but still queues some announcements for them, particularly transaction inventory messages. Ordinarily a peer that ignores a nonced ping for 20 minutes gets disconnected, which caps the damage.

That disconnect is not applied to peers that do not support BIP 31 nonced pings. A malicious peer could claim not to support the feature and then read slowly on purpose, letting the queue expand indefinitely — up to about 2MB an hour per inbound peer and 5MB an hour per outbound peer. Nodes run with -blocksonly are far less exposed. Loupe reported this one on 15 September; a developer going by L0rinc found the same thing six days later.

The undo-file bug that is mostly not worth exploiting

The third advisory, rated Low, is the most interesting to read and the least likely to affect anyone. Bitcoin Core stores the data needed to disconnect a block in rev*.dat undo files, one per block file. Block files are capped at 128 MiB; undo files have no cap at all, and positions inside them were stored as 32-bit integers.

That allows a theoretical corruption. A miner can produce valid blocks whose undo data is far larger than the blocks themselves, pushing one undo file past 4 GiB until the 32-bit position wraps and newer undo data overwrites older entries. If a reorg then tries to disconnect an affected block, the node cannot read what it needs and shuts down. Restarting does not help; recovery needs a full -reindex with a fixed version.

Getting there is the hard part. The transactions are nonstandard, an attacker would have to mine several thousand blocks of them — roughly a month of the network's entire block production — then have about 18 more land at the very end of one specific block file on the target, and win a two-block reorg replacing exactly the last of them. File layouts differ from node to node, so no single placement works everywhere.

On Windows and 32-bit systems the failure is easier to reach and worse. Positioning there is limited to 2 GiB, so once an undo file passes that size the node fails to write undo data and shuts down on every restart, with no reorg required. The fix moves positions to 64-bit integers and uses 64-bit positioning calls on Windows. Two exceptions remain: 32-bit systems still use 2 GiB calls, and a blocks directory on a FAT32 drive still hits the 4 GiB file limit. Both keep failing after the upgrade.

The policy change that made the timing possible

Bitcoin Core has historically graded vulnerabilities by severity and timed disclosure to match. Low-severity bugs went public two weeks after a major release containing the fix. Medium and high-severity bugs stayed embargoed until two weeks after the last affected release reached end of life, a wait that could stretch to about a year.

That framework assumed secrecy bought protection: time for users to upgrade before anyone knew what to look for. Antoine Poinsot argued on the Bitcoin Development Mailing List that this no longer holds when a language model can find the same flaw in an afternoon. “The embargo period achieves little but it delays the availability of a fixed release,” the new policy says. The change was submitted on 16 October and merged on 22 October.

Under the revised rules, triage can classify a bug as “easily discoverable” — findable “with minimal effort, such as through a simple LLM prompt”, a label not restricted to AI-found issues. Those get backported to every maintained major version, a point release as soon as possible, and an advisory published alongside the fix. Everything else keeps the old timeline. The release notes already carry the two-week pre-announcement for three further medium- and high-severity issues.

What to do if you run a node

Upgrade. The exact version depends on the branch you follow: 29.5, 30.4, 31.2 or 32.1 all contain the three fixes, with 31.2 and 32.1 shipping first on 27 October. Checking your version takes one command, and each release note is on the project's site.

If you run 32-bit software, or store blocks on a FAT32 drive, upgrading closes two of the three bugs but not the undo-file failure. Moving to a 64-bit build and a modern filesystem is the only real remedy. If you do not run a node, there is nothing to do, though it is worth knowing who operates the node your wallet relies on. The mining side of the network was not affected here at all.

Why AI changes the arithmetic for open source

This is not the first time automated reports have forced a change of habit. Earlier this year Core Lightning developers told operators to upgrade or take their nodes offline after receiving multiple AI-generated vulnerability reports, and held the details back for two weeks. What is new is the response: instead of defending the embargo, Bitcoin Core redefined when an embargo makes sense.

The economics are uncomfortable for every open-source project. Finding a bug has become cheap; verifying it, writing a fix, backporting it across four release branches and testing it has not. Loupe reports only findings backed by a demonstrable test case, the only practical defence against a flood of plausible-looking noise. Both approaches still depend on a human who can tell a real bug from a hallucinated one. The scanning got automated. The judgement did not.

What this does not mean

There is no reason to read this as a threat to bitcoin's monetary rules. A node that crashes and restarts is briefly absent, not one that accepts invalid blocks. The three flaws sit in networking, queue management and file handling, all well away from the consensus code that decides whether a transaction is valid. If you want the class of bug that actually threatens settlement, the double-spend problem is the place to look, and none of this week's disclosures touches it.

The market barely registered any of it. Bitcoin was trading near $80,000 on 29 October, down about 1.6% over 24 hours, in a technology-led risk-off move after the Federal Reserve held rates at 3.75%–4% with two policymakers dissenting in favour of a hike. Node advisories rarely move price, and these did not.

What they change is the timetable. Expect more of these, published faster and with less warning, as AI scanning spreads across the ecosystem's codebases. For node operators the rule is now the one that applies to any internet-facing server: when a point release lands with the word security in the notes, install it that week rather than next quarter.