Bitcoin Core discloses three node bugs found by AI scan, fixed in four releases

Bitcoin Core, the main software that runs the Bitcoin network, disclosed details of three bugs that could crash nodes on Oct. 28, after shipping fixes in versions 29.5, 30.4, 31.2 and 32.1 over two days. All three were first found not by a person but by an automated AI code scan.

According to the disclosures, all three issues were discovered through an automated LLM scan as part of Elias Rohrer's Project Loupe at Spiral. Bitcoin Core contributor Gregory Sanders validated the findings and passed them to the security team. Developers rated two of the bugs Medium severity and one Low, and described all three as "easily discoverable."

A single kind of TCP signal could take down Windows and Mac nodes

The most direct bug affects nodes running on operating systems other than Linux. Bitcoin Core protects its memory by temporarily pausing reads when too much data from a peer has queued up. But the select()-based socket monitoring used outside Linux kept reading when it received TCP urgent (out-of-band) data, even while reads were paused, letting a peer queue an unbounded amount of data.

"In practice, this means a malicious peer can trivially crash any Windows, macOS or BSD node it is connected to," the developers wrote. Linux uses poll() instead and is not affected. Project Loupe found the issue on Oct. 23, and three days later, on Oct. 26, the fix (PR #36665) was merged and backported to versions 29 through 32.

Paused peers could pile up as much as 5MB an hour

The second bug stemmed from Bitcoin Core continuing to queue transaction announcements for peers it had paused for being slow to read. Peers that fail to answer a ping within 20 minutes are normally disconnected, but that rule did not apply to peers claiming not to support BIP 31 nonced pings. An attacker could pose as such a peer and read messages slowly so the queue grew without limit.

Memory could grow by up to 2MB per hour per inbound peer and 5MB per hour per outbound peer. Nodes running with -blocksonly, which skip transaction announcements, are much less affected. Project Loupe flagged the issue first on Sept. 15, and developer L0rinc independently reported it on Sept. 21.

An attack that needs about a month of the network's blocks

The third bug came from storing positions in "undo" files, which nodes use to disconnect blocks during a reorg, as 32-bit integers. Once a single undo file passed 4 GiB, the position wrapped around and newer data could overwrite older data, so a node would shut down if it later had to disconnect an affected block. Restarting does not help; recovery requires a -reindex with a fixed version. On Windows and 32-bit systems, writes failed at 2 GiB, causing a shutdown on every restart.

The developers said exploiting this on 64-bit systems is "impractical." An attacker would have to mine several thousand blocks of nonstandard transactions, roughly a month of the entire network's block production, then land about 18 more blocks at precise spots in each node's own file layout and win a 2-block reorg. The fix stores positions as 64-bit integers and leaves the on-disk format unchanged. However, 32-bit systems and nodes keeping their blocks directory on a FAT32 file system remain affected. The issue was first reported on July 8, and L0rinc (Aug. 21) and Andrew Dorman (Oct. 23) later reported it independently.

Versions 31.2 and 32.1 came out on Oct. 27, followed by 29.5 and 30.4 on Oct. 28, the day of disclosure. The 32.1 release notes say 32.0 was tagged but never fully released due to last-minute issues, and that with the new major version, 29.x and older have reached end of life. Under the regular disclosure schedule, developers said they will disclose three medium- and high-severity vulnerabilities fixed in 30.0 in two weeks.