Bitcoin Core fixes three node vulnerabilities: check the version, OS and storage
Source report: 2026-10-28 · Editorial analysis published: 2026-10-29
October 28 advisories identify two memory-exhaustion issues and an impractical undo-file attack. Fixes are in 29.5, 30.4, 31.2 and 32.1, with remaining limits on 32-bit systems and FAT32.
Four patched versions address three different problems
Bitcoin Core published three security advisories on October 28 covering bugs that can exhaust a node’s memory or disrupt the files needed to undo blocks. Fixed versions are 29.5, 30.4, 31.2 and 32.1. Two issues are rated Medium and one Low. For a miner or pool running its own node, the practical concern is continuity: a stopped node can interrupt the local service used to validate blocks or prepare mining work.
The advisories describe different exposure, so “I use Linux” does not settle all three. Linux avoids the TCP-specific bug, but the paused-peer issue is separate; the undo-file fix also depends on architecture and filesystem. An ASIC’s firmware version is not the node version. First identify which Bitcoin Core process supplies the operation, on what operating system, and where its block files are stored.
A network peer can exhaust memory outside Linux
The TCP urgent-data issue affects the socket-monitoring path used on Windows, macOS and BSD. A malicious connected peer could bypass the node’s pause on incoming data and let its processing queue grow without a bound. The advisory says this can crash an affected node. Linux uses a different monitoring path and is not affected by this particular issue.
This is why an operator should not read the headline as one identical failure on every platform. The correction is included in the four named versions. The advisory credits an automated Project Loupe scan, followed by human validation and reporting to the security team; it is not a claim that an AI system autonomously repaired deployed nodes. Existing installations only receive the code when their operator actually updates them.
Another queue can grow slowly on old-style peers
The second Medium issue concerns peers that pretend not to support the older BIP31 ping-response mechanism. A slow peer can remain paused while announcements continue to enter its outgoing queue. The advisory reports growth of up to 2 MB per hour for an inbound peer and 5 MB per hour for an outbound peer. This is a slower accumulation problem, distinct from the first advisory’s readily triggered crash.
Nodes using blocksonly mode are much less affected because transaction announcements make up most queued messages. The source says less affected, not immune, and the setting is not a substitute for installing a fixed version. For an operator, check the running node rather than assume an update to a monitoring dashboard or mining client also replaced Bitcoin Core underneath it.
The undo-file bug has unusual requirements and remaining limits
Undo data records spent outputs so a node can disconnect a block during a chain reorganization, when it switches to a competing valid history. The Low-severity bug stored file positions with too few bits. Under extreme conditions, a miner could create enough unusually large undo data to corrupt those positions and eventually stop affected nodes. The developers call exploitation on 64-bit systems impractical: it would require several thousand specially constructed blocks and additional precise conditions.
The fix uses wider file positions, including the relevant Windows calls, without changing the serialized on-disk format. However, the advisories explicitly say 32-bit systems remain affected, as do block directories on FAT32, which has its own 4 GiB file limit. A patched version number therefore does not make an unsuitable architecture or filesystem disappear. Check the actual storage used by the node, including an external drive, rather than only the desktop’s operating-system name.
If this issue has already corrupted undo data, the advisory says restarting alone does not repair it; recovery requires reindexing with a fixed version. That is a recovery case, not a reason to reindex every healthy node after updating. Preserve wallet backups and follow the applicable release instructions before maintenance. We reviewed the advisories without installing a node, modifying wallets or carrying out recovery operations.
Choose a maintained branch and verify the running result
Version 29.5 is on the fix list, but 29.x reached end of life with the release of major version 32. The project’s life-cycle policy normally maintains the newest three major versions, now 30.x, 31.x and 32.x, and recommends the latest maintenance release of the newest branch an operator can use. Receiving this backport does not reopen long-term maintenance for 29.x.
For a mining setup, record the current version, OS architecture and block-directory filesystem, plan the normal upgrade and then confirm the version actually running, peer connections and synchronization. Finally check the service that depends on it, such as the pool’s work-generation path. A successful installer is not the same observation as a resumed mining service. The reason to act is the published patch, not an unsupported claim that coins have been stolen through these three bugs.
The team’s announcement distinguishes these three disclosed issues from a separate set pre-announced with the major release and scheduled for later disclosure. Do not combine the counts or invent missing details. The clear takeaway is that patches are available now, platform differences matter, and 32-bit or FAT32 installations need attention beyond simply selecting one of the four version numbers.
Source: Bitcoin Core ↗ · Paused-peer memory advisory ↗ · Undo-file overflow advisory ↗ · Software maintenance life cycle ↗ · Bitcoin Core 32.1 release ↗
Mining calculator ↗
