Bitcoin Core disclosed three vulnerabilities on October 28, 2026, after distributing fixes in versions 29.5, 30.4, 31.2 and 32.1. Two of the flaws can exhaust a Bitcoin node’s memory; the third involves corruption or failed writes of block undo data under unusually demanding conditions. The Bitcoin Core team rates two issues Medium severity and one Low, but their effects and the systems at risk are not identical.
The most direct remote-crash scenario affects Bitcoin Core nodes on Windows, macOS and BSD, while a separate peer-related memory issue can affect other operating systems, including Linux. Crucially, the undo-file fix is not complete for 32-bit systems or nodes using FAT32 storage. The disclosures concern availability and reliable operation of Bitcoin Core nodes; they are not an announcement that the Bitcoin protocol has been hacked or that private keys have been stolen.
What Did Bitcoin Core Fix in October 2026?
The official Bitcoin Core security advisory index identifies three newly disclosed CVEs. The following comparison separates their triggers, official severity ratings and residual risks rather than grouping them into a single generic “Bitcoin bug.”
| Vulnerability | Bitcoin Core severity | Potential impact | Key limitation |
|---|---|---|---|
| CVE-2026-117350 | Medium | A malicious peer can exhaust memory through TCP urgent data, crashing a connected node | Specific to the non-Linux socket-monitoring path |
| CVE-2026-117349 | Medium | A slow-reading peer can cause outgoing announcements to accumulate without a bound | Can affect nodes across operating systems; growth is gradual |
| CVE-2026-117346 | Low | Extreme block sequences can cause undo-file overflow, corruption or failed writes | 64-bit fixes do not eliminate exposure on 32-bit systems or FAT32 |
All three advisories name 29.5, 30.4, 31.2 and 32.1 as releases containing the corresponding fixes, with the storage-related exception noted above. Version 32.1 was announced on October 27; the other version announcements and public CVE disclosures followed in the same release window. These are software-maintenance and security events, not a Bitcoin consensus-rule change.
CVE-2026-117350: Why Can a Network Peer Crash Windows and macOS Nodes?
Bitcoin Core applies limits to how much incoming peer data it queues for processing. On Windows, macOS and BSD, the relevant socket-event backend uses select(), while Linux uses a different poll() path. The CVE-2026-117350 advisory explains that the non-Linux backend continued handling exceptional socket events even when normal reads were supposed to be paused.
A malicious connected peer could send TCP urgent, or out-of-band, data to trigger that exceptional condition. The node would then read and queue more data despite its backpressure limit, allowing memory use to grow until the process failed. Bitcoin Core describes this path as capable of trivially crashing a connected Windows, macOS or BSD node.
This finding needs a precise qualification: Linux nodes are not affected by this particular CVE, because they use the other socket-monitoring backend. That does not mean a Linux node is exempt from the separate October memory-growth advisory. Operators must check the issues individually, not infer safety from the platform name alone.
CVE-2026-117349: How Can a Slow Peer Keep Increasing Memory Use?
The second Medium-severity issue has a different mechanism. When a peer reads too slowly, Bitcoin Core is designed to pause sending once the outgoing message queue reaches a limit. However, the node could still add announcements, especially transaction inventory messages, to that queue. Ordinarily, a peer failing to respond to a ping would be disconnected after a timeout.
According to the CVE-2026-117349 advisory, a malicious peer could claim not to support the nonced ping feature introduced by BIP 31 and strategically avoid reading messages. The expected disconnect would not apply, and queued messages could accumulate over time.
Bitcoin Core estimates memory growth of up to 2 megabytes per hour for each affected inbound peer and 5 megabytes per hour for each affected outbound peer. Those are advisory estimates per peer, not an observed memory-loss rate for every node. The cumulative impact depends on peer connections and how long the behavior continues.
Nodes started with the -blocksonly option are substantially less exposed because they relay far fewer transaction announcements. Less exposure, however, is not the same as a patch. The corrected releases address the faulty queue-handling behavior rather than relying on operators to disable normal transaction relay.
CVE-2026-117346: What Is an Undo-File Overflow, and What Remains Unfixed?
Bitcoin Core keeps block data in files such as blk*.dat and corresponding undo data in rev*.dat. Undo information allows a node to reverse the effects of a block if a chain reorganization requires disconnecting it. The CVE-2026-117346 advisory explains that, unlike block files, undo files had no equivalent size cap, while recorded positions used 32-bit integers.
In a specially constructed extreme scenario, a miner could fill an undo file beyond roughly 4 GiB, causing its position counter to wrap. This could overwrite or truncate undo data and cause the node to shut down when an affected block needed to be disconnected. The advisory says exploiting the reorganization scenario on 64-bit systems is impractical: it would require substantial mining control, thousands of specially constructed blocks and unusually precise timing.
On Windows and 32-bit systems, the underlying file-positioning limitation could instead cause a write failure after approximately 2 GiB of undo data, potentially preventing the node from restarting successfully. The fixes switch to 64-bit positions and, on Windows, 64-bit file-positioning calls. But the project’s advisory explicitly says 32-bit builds remain affected. Nodes whose blocks directory is stored on FAT32 also remain vulnerable because that filesystem cannot hold a file exceeding its 4 GiB limit.
These residual cases matter more than a simple “patched” label suggests. Operators using 32-bit hardware or FAT32 storage should plan a supported 64-bit environment and filesystem migration rather than assume installing a numbered release alone fully addresses the undo-file issue.
Which Bitcoin Core Versions Contain the Security Fixes?
Bitcoin Core lists the relevant patched versions as 32.1, 31.2, 30.4 and 29.5. Its 32.1 release notes also clarify that version 32.0 was tagged but never fully announced or released, so operators should not treat an unofficial 32.0 download as the preferred upgrade path.
There is an important lifecycle distinction. Although 29.5 contains these three fixes, the Bitcoin Core software lifecycle policy says the 29.x branch became end-of-life on October 27, 2026, following the 32.x release. A final security backport does not mean that branch will receive regular future updates. Versions 30.x, 31.x and 32.x are the maintained major branches at this point in the project lifecycle.
For a node operator, selecting a release requires more than finding the first version number on a list. Check operating-system architecture, storage format, dependent software and the current maintenance policy. Operators who need a conservative upgrade path can review the latest supported maintenance release for their branch, while planning to leave end-of-life versions behind. The 32-bit and FAT32 limitations still require separate attention.
Were the Bitcoin Core Bugs Discovered by Artificial Intelligence?
Yes, with an important distinction between detection and verification. The three official advisories credit Project Loupe at Spiral, an automated large-language-model scanning effort associated with Elias Rohrer, for identifying the underlying issues. They also say Gregory Sanders validated and brought the reports to Bitcoin Core’s security team. Independent researchers subsequently reported some overlapping findings.
The discovery dates were not identical: the advisory history places the slow-peer memory issue in September, the undo-file finding in July and the TCP urgent-data issue on October 23. The project merged fixes and backported them across release branches before making the details public on October 28. It would therefore be misleading to imply that a single AI-generated report exposed three previously unreviewed weaknesses overnight.
Automated code analysis helped identify unusual execution paths; human review determined their validity and supported the patch process. These disclosures do not establish that AI exploited live Bitcoin nodes. They also do not provide evidence of stolen coins, a broken signature algorithm or an inflation vulnerability in Bitcoin’s monetary rules.
What Should Bitcoin Node Operators Do Now?
First, identify the software version and environment actually running the node. Check the Bitcoin Core application’s version or the node’s reported network information, then compare it with the project’s maintained releases. Record whether the node is on Windows, macOS, Linux or BSD, whether the operating system is 32-bit or 64-bit, and what filesystem holds its block data.
Second, obtain an appropriate release from the official source. The Bitcoin Core download page provides the installer packages, SHA-256 checksums, signature files and platform-specific verification instructions. Verify the download against trusted release signatures, review release notes and ensure any wallet backups and operational recovery plans are in place before making changes. Shut down the node cleanly and follow the appropriate installation procedure.
Third, consider the residual storage risks. Updating a 32-bit machine or a node whose block directory resides on FAT32 is not a complete remedy for CVE-2026-117346. Review migration options for a supported 64-bit setup and suitable filesystem. After restarting, check that the intended version is running and that the node can connect, validate blocks and operate normally; administrators of business-critical services should also check dependent applications.
These advisories describe potential disruptions to Bitcoin Core node availability, not a confirmed network-wide failure. Ordinary users who do not operate Bitcoin Core should verify whether their wallet, exchange or service provider is affected before taking action. The disclosures do not, by themselves, justify sending coins to a new address, importing a recovery phrase into an unfamiliar tool or installing software from an unsolicited message.
The bottom line: Bitcoin Core’s October 28 disclosures address three distinct node-security issues across four releases. Two bugs could increase memory use until a node fails; an extreme undo-file scenario could disrupt block processing, with important 32-bit and FAT32 exceptions to the fix. Node operators should prioritize verified supported builds and appropriate system configurations, while distinguishing real software risks from unsupported claims that Bitcoin’s underlying ledger has been compromised.