Updated October 31, 2026.
Bitcoin Core published three security advisories on October 28 concerning vulnerabilities that can disrupt nodes. Fixes are included in versions 29.5, 30.4, 31.2 and 32.1, but the affected platforms differ, and the undo-file issue retains important limitations on 32-bit systems and FAT32 storage.
The most immediate case concerns Windows, macOS and BSD: a connected malicious peer can exhaust memory through TCP urgent data. Linux is not affected by that particular flaw. This does not exempt Linux from the other advisories, or mean that every instance of high memory usage proves an attack.
Bitcoin Core versions containing the fixes
The three advisories identify the same four patched releases. The project announced Bitcoin Core 32.1 on its official website. Choosing an upgrade also requires reading the relevant release notes and checking compatibility with the actual installation rather than relying on a version number in isolation.
A list of patched releases is not advice to remain indefinitely on an older branch. It establishes where these fixes were distributed, not a guarantee of ongoing maintenance for every branch. This article describes the information available on October 31; subsequent releases should be assessed against the project’s own documentation.
| Advisory | Issue | Important qualification |
|---|---|---|
| CVE-2026-117350 | Unbounded memory through TCP urgent data | Non-Linux code path; medium severity |
| CVE-2026-117349 | Slow announcement-queue growth with pre-BIP31 peers | Separate from the TCP flaw; medium severity |
| CVE-2026-117346 | Undo-file overflow | Extreme conditions; low severity, residual 32-bit/FAT32 limitations |
The TCP flaw does not affect Linux
The TCP advisory concerns the socket-monitoring path based on select(), rather than the path used on Linux. An exceptional socket condition could trigger another read even after ordinary reads had been paused to control the processing queue.
This could allow memory consumption to grow until the node crashed. The project rates the issue medium severity and describes an attack by a connected peer, not access to private keys. What matters is the platform running the node, not the operating system of a phone used to look up its owner’s balance.
A second flaw gradually expands an outgoing queue
The pre-BIP31 advisory concerns announcements queued for a peer that is reading too slowly. A peer could claim not to support BIP31 nonce-based pings and avoid the normal disconnection mechanism associated with an unanswered ping, while the queue continued to accumulate messages.
The advisory describes growth of up to 2 MB per hour per inbound peer and 5 MB per hour per outbound peer. Those are scenario-specific figures, not forecasts for every node’s memory use. Nodes using -blocksonly are much less affected because transaction announcements account for most of the queued messages, but that observation is not a replacement for patching.
Undo files: why 32-bit systems and FAT32 still matter
Undo data lets a node disconnect blocks during a chain reorganization. The overflow advisory describes extreme conditions in which unusually large undo data can corrupt information needed by the node and cause it to shut down. The project rates the issue low severity and considers exploitation impractical on 64-bit systems under the described conditions.
The fix uses 64-bit positions, but the advisory explicitly retains limitations for 32-bit systems and block directories stored on FAT32. Installing a patched version therefore does not make architecture and filesystem irrelevant. Windows file-positioning calls also received a fix; this should not be confused with the separate, continuing limitations on 32-bit systems.
A node crash is not proof of wallet theft
These disclosures do not announce automatic extraction of seed phrases or private keys. Node operation and custody are distinct responsibilities, as our explanation of custodial and non-custodial wallets sets out. A service interruption still matters, but it does not by itself establish that an owner’s bitcoin has been stolen.
Other errors have different causes. The max-fee-exceeded message, for example, concerns a fee safeguard rather than one of these vulnerabilities. Treating every warning as the same incident can lead to unnecessary or unsafe interventions. The running version, platform and documented symptom need to be established first.
What operators can check before attempting recovery
The advisories attribute the findings to a language-model scan conducted through Project Loupe and identify human validation before the reports reached the security team. That sequence matters: an automated finding, a verified vulnerability and a distributed patch are different stages. It does not demonstrate that a model can autonomously repair arbitrary software or remove the need for maintainers.
Independent rediscoveries are also recorded for two of the issues. AI involvement does not change the operator’s practical responsibility: establish which code is actually running and which documented conditions apply to that machine, rather than drawing conclusions from a headline about automated discovery.
Start with the version actually running, operating system, architecture and filesystem holding the blocks directory. Obtain updates through official channels, follow the project’s authenticity checks and preserve wallet backups. A legitimate software update never requires sharing a seed phrase with a support service, an online form or a person offering to repair the node.
The undo advisory mentions reindexing with a fixed version to recover from the specific corruption it describes. That is not an instruction to run -reindex whenever a node is slow. Diagnosis, data protection and resource requirements come first; CryptoRoad has not reproduced the attacks or tested an installation here, but has compared the published fixes and their stated limitations.
