Three security flaws in Bitcoin Core: what you can do now

Bitcoin Core published three security advisories at once on October 28, 2026. The most serious of them lets a single malicious peer crash any node running on Windows, macOS or BSD. All three points are fixed in versions 29.5, 30.4, 31.2 and 32.1. If you run your own Bitcoin node and have not updated since Monday, you are running a build whose weaknesses have been described publicly since Wednesday.

A node is the machine that verifies the entire blockchain itself instead of trusting a provider. If it goes down, no balance disappears: the keys sit in the wallet, not in the node. What is lost is your own verification, and with two of the three bugs the machine goes down with it.

Three advisories in one day: what Bitcoin Core disclosed

The three publications stand together in the project's advisory list. Two of them are rated “Medium”, one “Low”, and all three carry the note “easily discoverable”. That is the decisive rating: anyone reading the code finds the spot without particular effort.

• TCP urgent data: a peer can crash a node on Windows, macOS or BSD. Linux is not affected.
• Paused pre-BIP31 peers: a node's memory requirement grows slowly, but without a limit.
• Undo file overflow: a miner can corrupt other nodes' recovery data.

The sequence of publications is unusually tightly timed. The fixes were merged on October 26 and backported to branches 29, 30, 31 and 32. On October 27 versions 31.2 and 32.1 appeared, on October 28 followed 29.5 and 30.4, and on the same day the description of the bugs went online.

TCP urgent data: why Windows and macOS nodes crash

Bitcoin Core limits how much data it holds per peer for processing. If the queue grows too long, the software pauses reading from that socket. This mechanism is called backpressure: the software slows the peer down instead of filling up itself.

That very brake can be bypassed. On systems other than Linux, Bitcoin Core monitors network sockets with an older technique that also reacts to so-called exceptional conditions on a socket. Until now it did so even when reading had long been paused. A peer therefore only has to send TCP urgent data, a rarely used form of out-of-band transmission, and the node keeps reading. The queue grows without limit until memory is full.

The project describes the consequence in its advisory in unmistakable terms: a malicious peer can crash any connected node on Windows, macOS or BSD this way. No lead time, no preparation, no computing power. The flaw was reported on October 23 and the bug was fixed three days later.

Backpressure: the brake that fails here

Why this was possible at all comes down to a peculiarity of the implementation. On Linux, Bitcoin Core uses a different method to monitor network sockets. The faulty path simply does not exist there. Nodes on Linux servers, on most ready-made home node boxes and in data centres are therefore untouched by this point.

select() instead of poll(): Linux nodes are not affected

In practice this is the most important distinction of the whole day. Run your node on a single-board computer or a small Linux server and this bug passes you by. Run Bitcoin Core as a program on your work machine instead, meaning on Windows or on a Mac, and you belong to the affected group. The same applies to nodes on BSD systems.

The difference is not theoretical. A crashed node stops syncing, answers no queries from your own wallet and reports no incoming payments. If you run your wallet against your own node, you see an outdated balance during that time.

Pre-BIP31 peers: 2 MB of memory per hour and connection

The second bug works more slowly and is therefore more insidious. Bitcoin Core queues announcements for all peers, including those already paused. Those consist above all of the frequent notices about new transactions.

Normally that is harmless, because a peer is disconnected if it fails to answer a check message for twenty minutes. This check message is described in BIP 31, an improvement proposal from the network's early days that adds a random number to the ping message. Peers that do not support BIP 31 are exempted from this disconnection. A peer therefore only has to play old and delay reading on purpose.

The project quantifies the growth precisely: up to 2 MB per hour and inbound connection, up to 5 MB per hour and outbound connection. A node with many inbound connections gathers enough ballast this way over days to fill up memory. Considerably less affected are nodes running with the -blocksonly setting, because there the transaction announcements that make up the bulk of the queue fall away.

This point was reported as early as September 15, 2026. A good six weeks therefore lay between report and fix, in which the flaw was known to the project and not to the public.

Undo files above 4 GiB: the third bug in the rev directory

The third point concerns a file most node operators have never heard of. Alongside the block files, Bitcoin Core writes so-called undo files, recognisable by the name pattern rev*.dat. They record which coins a block spent. The software needs these details when a reorganisation of the blockchain has to unwind a block already booked.

A reorganisation, reorg for short, is the process in which the network switches to a different, longer chain of blocks and takes back previously valid blocks. Block files are capped at 128 MiB; the undo files, by contrast, never had an upper limit. The positions inside them were stored as 32-bit numbers, and those only reach 4 GiB.

A miner can build valid blocks whose undo data is considerably larger than the blocks themselves. If an undo file grows beyond those 4 GiB, the position marker jumps back to the beginning. Newer undo data overwrites older data, and the file is truncated to the jumped-back length. If a later reorganisation unwinds an affected block, the node can no longer read its undo data and shuts down. A restart does not help. Recovery requires a complete rebuild of the index with a corrected version, a matter of hours to days on an ordinary home machine.

32-bit systems and FAT32 stay vulnerable even after the update

Here lies the point that, unlike the other two, is not fully settled. The overflow was fixed by storing the positions as 64-bit numbers and having Windows use the matching file calls. The format on disk stays unchanged, so moving the data is not necessary.

Two constellations remain exposed nonetheless. On 32-bit systems the file calls still work only up to 2 GiB, so the bug occurs there at half the data volume already, and without any reorganisation. And if your block directory sits on a FAT32 file system, for instance on an older external drive or a USB stick, you hit that format's file limit of 4 GiB. In both cases writing the undo data fails, and the node shuts down again at every start.

Exploiting the bug in practice is barely feasible on 64-bit systems. The project describes the effort in detail: the necessary transactions are not standard-compliant, an attacker would have to mine several thousand such blocks, which corresponds to roughly a month of the entire network's block production, and afterwards around eighteen further blocks of his would have to land exactly at the end of a block file on the target node. Finally he would have to win a reorganisation across two blocks. Since the file layout differs from node to node, no single preparation hits all targets.

Project Loupe: an automated scan found all three flaws

All three bugs trace back to the same source. They were found by an automated scan with a language model that runs under the name Project Loupe at Spiral and is led by Elias Rohrer. Gregory Sanders verified the findings and reported them to the Bitcoin Core security team.

Two of the three points were discovered a second time independently. Developer L0rinc reported the memory bug with paused peers on September 21 and the undo overflow on August 21, and Andrew Dorman reported the undo overflow on October 23. The fixes came from Antoine Poinsot in each case.

From embargo to disclosure: Bitcoin Core has changed the rules

That the descriptions stood public just one day after the finished versions is no coincidence. The project only recently changed its publication practice and gave up the long embargo period, which we reported on October 23, 2026: Bitcoin Core drops the embargo. The three advisories of October 28 are the first larger run under the new line.

For operators that has two sides. The flaws become known faster, and anyone who does not update is open to attack sooner. At the same time it is now set out in readable form what exactly can go wrong, instead of just a version number with the note “security update”.

Without your own node: where your Bitcoin balance sits then

The larger share of investors run no node of their own. Hold your coins in a software wallet on your phone or your computer and you are using other people's nodes, usually those of the wallet provider. Which wallet takes which route and where you can switch on your own verification is set out in the comparison of software wallets.

Nobody in this group is directly affected by the three bugs. A risk remains nonetheless: if the provider's node goes down, you see no current balance and get no payment confirmed. Your keys sit untouched in the wallet, and that is the whole point of self-custody.

The price did not react to the publication. Bitcoin traded at around $79,790 on the morning of October 29, 2026 (CoinGecko), about 1.6 percent below the previous day, in step with the rest of the market after the US Federal Reserve's rate decision the day before.

Bitcoin Core 32.1: stay on 32-bit and you stay vulnerable

1. Check the version and switch. In the console, bitcoin-cli getnetworkinfo shows the running version. Anything below 29.5, 30.4, 31.2 or 32.1 belongs replaced, especially on Windows and macOS. If you want to take the opportunity to separate the keys from your everyday machine, the devices are listed in the hardware wallet comparison.
2. Look at the file system and the architecture. If the block directory sits on FAT32 or the node runs on a 32-bit system, the third bug stays open. Moving to a modern file system removes it. If you would rather rely entirely on a provider, compare the fees in the overview of crypto exchanges.
3. Watch memory consumption. If an older node's consumption grows steadily over days, that matches the second bug. With -blocksonly the growth turns out considerably smaller. If you prefer to keep your balance at a supervised firm, check the authorisations among the regulated crypto exchanges.

The full descriptions stand in the Bitcoin Core advisory list, and the text on the TCP flaw in the individual advisory.

(As of October 29, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)