Bitcoin Core Fixes Low-Severity Undo File Overflow Vulnerability

Bitcoin Core developers disclosed a low-severity vulnerability on Oct. 28 that could allow miners to corrupt node undo data and cause software shutdowns under specific reorganization conditions ¹. The bug has been resolved across 64-bit systems in Bitcoin Core versions 29.5, 30.4, 31.2, and 32.1, according to the project's security advisory ¹. At the time of writing, $BTC traded around $80,709.

Bitcoin Core relies on undo data stored in rev*.dat files to disconnect blocks during a chain reorganization ¹. While block files are limited to 128 MiB, undo files lacked a maximum size constraint, and positions were recorded using 32-bit integers ¹. A miner producing blocks with extensive undo data could push a file past 4 GiB, causing the 32-bit integer to wrap, overwrite older data, and truncate the file ¹. Should a node subsequently reorganize an affected block, it fails to read the necessary undo information and halts operation, requiring a full reindex with a patched version to recover ¹. On Windows and 32-bit operating systems, where file positioning calls were constrained to 2 GiB, writes failed immediately upon crossing that threshold without requiring a chain reorg ¹.

Practical Constraints and Lingering Exposures

Bitcoin Core maintainers categorized exploitation as impractical ¹. To trigger the overflow on 64-bit machines, an attacker would need to mine several thousand nonstandard transaction blocks—equivalent to about a month of entire network output—and successfully execute a precise two-block reorganization targeting varying local file layouts ¹. In theory, deeper control could allow an attacker to restore incorrect coins during a reorganization, thereby corrupting a node's UTXO set ¹.

The software patch addresses the issue by storing file positions as 64-bit integers and applying 64-bit positioning calls on Windows ¹. However, 32-bit platforms and nodes hosting block directories on FAT32 file systems remain vulnerable due to inherent 2 GiB and 4 GiB operating boundaries ¹. The vulnerability was originally identified on July 8 by Elias Rohrer's automated model-assisted security initiative, Project Loupe at Spiral, and confirmed to core maintainers by Gregory Sanders before independent disclosures in August and October ¹.