On October 28, 2026, the Bitcoin Core development team disclosed details of three vulnerabilities patched across versions 29.5, 30.4, 31.2, and 32.1. All three were identified through an automated scan using large language models, then verified by humans before being reported to the project’s security team.
The scan was conducted as part of Project Loupe by Elias Rohrer at Spiral. Gregory Sanders verified the findings and forwarded them to the Bitcoin Core team. The incident took place less than a week after the project updated its vulnerability disclosure policy to favor earlier public disclosures for bugs that AI can easily identify.
The most critical bug only affects non-Linux nodes
The first flaw involves how Bitcoin Core monitors socket events on platforms other than Linux. On Linux, the software relies on poll; on Windows, macOS, and BSD, it relies on select. The select-based implementation monitors socket exception conditions even when reads have been paused to control queue sizes.
A malicious peer could send TCP urgent data to trigger that condition, forcing the node to process additional data and bypassing the rate-limiting mechanism. According to the project’s description, an attacker could crash any connected Windows, macOS, or BSD node. The issue was classified as medium severity and easy to discover. Nodes running Linux are unaffected.
The second bug causes slow, unbounded memory growth
The second vulnerability involves legacy peers that do not support BIP 31 ping messages with nonces. For these peers, the automatic disconnection triggered after 20 minutes without a ping response was not enforced, allowing a peer to pretend it lacks support for the newer standard and delay reads so that buffers gradually swell.
Observed memory growth reached up to 2 MB per hour per inbound peer and 5 MB per hour per outbound peer. Classified as a medium-severity bug, it was initially reported on September 15 along with an independent report from L0rinc.
The third bug is difficult to exploit but not fully patched
The remaining vulnerability lies in undo files, where Bitcoin Core stores the data needed to roll back a block during a chain reorganization. File positions within undo files are tracked using 32-bit integers; if an undo file exceeds 4 GiB, the position counter wraps around, causing new writes to overwrite older data.
In theory, a miner could produce a sequence of blocks that pushes the undo file past this limit, then time a reorganization so that other nodes fail to read the corrupted undo data and crash. However, the project considers exploitation impractical on 64-bit systems, as it would require mining thousands of blocks containing non-standard transactions—roughly equivalent to a month of total network block production—followed by winning a two-block reorganization race.
The patch upgrades file positions to 64-bit integers and implements 64-bit file-seeking operations on Windows. However, 32-bit systems and nodes storing blocks on FAT32-formatted partitions remain affected due to underlying platform file-size limitations.
Timeline highlights response speed
The third flaw was first reported on July 08, followed by two independent reports on August 21 and October 23. By October 26, pull requests were opened, merged, and backported to branches 29, 30, 31, and 32. Versions 31.2 and 32.1 were released on October 27, while versions 29.5 and 30.4 were released on October 28, the same day as the public disclosure.
Notably, all three vulnerabilities were identified using the same workflow: AI-assisted source code scanning followed by human verification. This reflects the practical reality of the wave of AI vulnerability hunting reshaping how open-source projects manage embargo timelines. For node operators, the required action is straightforward: verify current version numbers and upgrade if running older release branches.