Three cards showing the share of reachable Bitcoin Core nodes that, in the btcnodes.io snapshot of November 11, 2026, advertised a version without each fix: 21.7% (3,935 of 18,147) without the block-processing fix (CVE-2025-62859), 10.4% (1,887 of 18,147) in the range of the mining bug (CVE-2025-62861), and 18.9% of Core nodes reachable over Tor (1,584 of 8,384) without the Tor fix (CVE-2025-62860).
Our own chart, built from the figures in this article: count of reachable Bitcoin Core nodes in the btcnodes.io snapshot of November 11, 2026, 09:12 UTC.

Three Bitcoin Core Vulnerabilities Are Now Public: Is Your Node Affected? A Version-by-Version Guide

NodeWitness Team 10 min read

Bitcoin Core published three bugs on November 10 that had been fixed for about a year. The high-severity one leaves a miner unable to build blocks after a chain reorganization. The two medium ones let a peer stall block processing, or hand trusted-peer privileges to anyone who connects over Tor. If you run 30.0 or later, or 29.2 or later, you are covered. If you are still on the 28 series, you are not fully covered.

The three advisories went up on bitcoincore.org on November 10, 2026, and Antoine Poinsot announced them on the Bitcoin development mailing list at 20:39 UTC (3:39 p.m. Eastern) [1][2][3][4]. Nobody was caught off guard. The 32.1 release announcement on October 28 said three medium- and high-severity bugs fixed in 30.0 would be disclosed two weeks later [5], and our Bitcoin Core 32.1 checklist flagged the date. Core's policy is to publish details two weeks after the last affected series reaches end of life, and 29.x got there on October 27 [6].

The advisories are worth reading. The question that matters for you, though, is simpler: is your node on a release with the fixes? Here is the short version.

Am I affected? Check your version

Your Bitcoin Core version Block processing stall (CVE-2025-62859, medium) Mining halted after a reorg (CVE-2025-62861, high) Tor peers get trusted permissions (CVE-2025-62860, medium)
30.0 or later (30.x, 31.x, 32.x) No No No
29.2 to 29.5 No No No
29.0 or 29.1 Yes Yes Yes, if you use whitelist
28.3 or 28.4 Yes No No
28.0 to 28.2 Yes Yes Yes, if you use whitelist
27.x or older Yes No Yes, if you use whitelist

Table sources: the three advisories [2][3][4] and the 28.3, 28.4 and 29.2 release notes [7][8][9].

The surprising row is 28.3 and 28.4. Those releases got the Tor fix and the reorg fix, but the block-processing fix was only backported to 29.x [2][7][8]. The 28 series stopped getting patches on April 19, 2026, so that fix is not coming [6]. And while 29.2 and later are clean for these three bugs, 29.x itself reached end of life on October 27, so the next bug found there will not be patched. The supported series are 30.x, 31.x and 32.x, currently at 30.4, 31.2 and 32.1 [6].

How to check what your node is really running

Ask the running node:

bitcoin-cli getnetworkinfo

version returns a number such as 320100 (32.1.0) or 280300 (28.3.0), and subversion spells it out, as in /Satoshi:32.1.0/. Do not rely on bitcoin-cli -version. It reports the version of the bitcoin-cli binary you just typed, not the daemon, and after a half-finished upgrade the two can differ. In the desktop app, it is under Window → Information.

The Tor bug needs a second check, in bitcoin.conf:

grep -E '^(whitelist|whitebind)=' bitcoin.conf

If you see a whitelist= line whose range includes your Tor daemon's address (almost always 127.0.0.1 or an internal Docker network) and your version is older than 28.3 or 29.2, you match the advisory [3]. You can also run bitcoin-cli getpeerinfo and look at peers with "network": "onion" and "inbound": true. On a patched node their permissions list should be empty.

What the popular node bundles ship

We checked each project's repositories and release pages on November 11. They are not all equally clear, so this is only what we could verify.

  • Umbrel. The Bitcoin Node app 1.5.0, released October 30, lets you pick 32.1, 31.2, 30.4 or 29.5; if you left it set to always run the latest release, you are already on 32.1 [10]. The 1.0.x versions of the app shipped 29.1, which has all three bugs [10]. The app's current code grants trusted permissions through whitebind on an internal port, not through a whitelist range [11].
  • Start9. The Bitcoin Core package for StartOS published 31.2, 30.4, 29.5 and also 28.4 on November 9 [12]. If you picked 28.4, the block-processing bug still applies.
  • RaspiBlitz. The latest release, 1.12.1 from March 3, 2026, installs 29.2 [13]. That has all three fixes, on a series that is now out of support.
  • myNode. Its repository moved to 32.1 on November 8, except on devices running Debian older than 12, which stay on 27.2 [14]. Its default bitcoin.conf includes whitelist=127.0.0.1, and the box's Tor daemon connects from that same address [15]. On 27.2, that is exactly the setup the Tor advisory describes.

Whatever the app store says, the version your box is running is the one getnetworkinfo reports.

The three bugs, without the jargon

Block processing stall (CVE-2025-62859, medium). New blocks usually arrive in compact form, and the node rebuilds them from transactions it already has. Affected versions cleared the download state before checking that the witness data (the segwit part) had not been tampered with. If that check failed, the node asked the same peer for the full block and gave it a 10-minute timeout [2]. A malicious peer that announces the block first can use that to slow a node down, and if it controls the node's three high-bandwidth peers, or the node runs with -blocksonly, it can keep doing it indefinitely [2]. Eugene Siegel found it. For a home node, it means seeing blocks late. If you run Lightning on top, falling behind the chain is not harmless.

Mining halted after a reorg (CVE-2025-62861, high). TRUC, or version 3, transactions (BIP 431) may have at most one unconfirmed parent and one unconfirmed child in the mempool. That is a relay rule, not a consensus rule, so a valid block can contain any shape [4]. When the chain reorganizes, transactions from the dropped blocks go back into the mempool without the usual limits, but on 28.0–28.2 and 29.0–29.1 TRUC sibling eviction still ran. It could evict a restored transaction and leave its children behind, spending outputs that no longer existed [4]. With the mempool in that state, the block template fails its own validity check and the node cannot produce blocks until it restarts [4]. Niklas Gögge found it. It matters to anyone mining against their own node, including people solo mining from home who build their own template; a node that does not mine is, in practice, unaffected.

Tor peers get trusted permissions (CVE-2025-62860, medium). To Bitcoin Core, an inbound Tor peer appears to come from the Tor daemon's address, which usually sits on the same machine [3]. The -whitelist option marks a network as trusted and lifts denial-of-service limits and privacy protections. If its range covered the Tor daemon, every Tor peer got that trust [3]. According to the announcement, it could be used to knock a node over or make it leak internal state [1]. Several vendors shipped Bitcoin Core with Tor and that whitelist setting, which left thousands of reachable nodes treating any Tor peer as trusted [3]. Martin Zumsande and Antoine Poinsot found it and, in September 2025, also told Bitcoin Knots maintainer Luke Dashjr seperately [3].

What our node saw

If your node runs 29.2, 30.0 or later, none of the three bugs affects you. At 10:13 UTC on November 11, at block 975,425, it had 10 outbound connections to other nodes [16]. Five of them advertised Bitcoin Core versions older than 29.2 and outside 30.0 and later: 28.0, 27.0, 22.0, 0.21.0 and 0.20.0 [16]. That is a small sample, and each peer reports its own version, but it shows how much old software is still out there.

For the wider picture, the reachable-node crawler btcnodes.io counted 20,244 nodes at 09:12 UTC on November 11, of which 18,147 advertised Bitcoin Core without Knots [17]. Of those, 3,935 (21.7%) ran a version without the block-processing fix, and 1,887 (10.4%) fell in the range of the mining bug [17]. Among the 8,384 Bitcoin Core nodes reachable over Tor, 1,584 lacked the Tor fix. From the outside there is no way to tell how many of them use whitelist, which is what actually exposes them [17].

What to do

  1. Check your version with getnetworkinfo. On 30.0 or later, or 29.2 or later, there is nothing to do about these three bugs.
  2. On any 28.x release (28.4 included), or on 29.0 or 29.1, upgrade. A supported series (30.4, 31.2 or 32.1) is a better target than 29.5, because 29.x no longer gets patches [6]. Moving to 32.1 does not require a reindex or a wallet migration, as covered in the 32.1 checklist.
  3. If your node bundle lets you pin a version, check which one is pinned. App stores still offer releases with known bugs.
  4. If you cannot upgrade right away and have a whitelist that covers Tor, replace it with a whitebind on a dedicated port for your internal tools, or remove it.
  5. If you mine against your own node, make this the priority. A reorg involving TRUC transactions can leave you without templates untill you restart.

None of the three bugs touches consensus or, on its own, puts wallet funds at risk. But since November 10 they are public, with detailed write-ups, and Core has said that easily found bugs will now be disclosed as soon as fixed releases are out [5]. It is the same lesson as October's Linux kernel bug: a node is something you maintain, not something you install and forget. Live heights and network status are on Network and mining. And if you wonder why Core and Knots handle these advisories separately, see Bitcoin Core vs. Knots.

Sources

Source type in parentheses. Accessed November 11, 2026. Times in UTC unless noted.

  1. Antoine Poinsot, "Three Bitcoin Core security advisories," bitcoindev mailing list, November 10, 2026, 20:39 UTC. (Primary, development mailing list)
  2. Bitcoin Core, CVE-2025-62859 advisory, "Block processing stall via witness malleation", November 10, 2026. (Primary, official project site)
  3. Bitcoin Core, CVE-2025-62860 advisory, "Inbound Tor connections wrongly receive -whitelist permissions", November 10, 2026. (Primary, official project site)
  4. Bitcoin Core, CVE-2025-62861 advisory, "Block template creation halted by TRUC sibling eviction during reorg", November 10, 2026. (Primary, official project site)
  5. Bitcoin Core, 32.1 release announcement on bitcoindev, October 28, 2026. (Primary, development mailing list)
  6. Bitcoin Core, lifecycle policy and security policy. (Primary, official project site)
  7. Bitcoin Core, 28.3 release notes. (Primary, official repository)
  8. Bitcoin Core, 28.4 release notes. (Primary, official repository)
  9. Bitcoin Core, 29.2 release notes. (Primary, official repository)
  10. Umbrel, Bitcoin Node app manifest in umbrel-apps and its history. (Primary, project)
  11. Umbrel, bitcoind configuration in umbrel-bitcoin. (Primary, project)
  12. Start9, Bitcoin Core package releases for StartOS. (Primary, project)
  13. RaspiBlitz, release 1.12.1 and its Bitcoin Core install script. (Primary, project)
  14. myNode, app versions file. (Primary, project)
  15. myNode, default bitcoin.conf and bitcoin_tor.conf. (Primary, project)
  16. NodeWitness, reading from our node (full Bitcoin Core, unpruned) with getpeerinfo and getnetworkinfo, November 11, 2026, 10:13 UTC, block 975,425. (Primary, own data)
  17. Bitnodes, reachable-node snapshot (served from btcnodes.io), November 11, 2026, 09:12 UTC; our own count by advertised version. (Secondary, network crawler)

None of these advisories changes a single chain rule: a node on 28.4 and one on 32.1 follow the same block. What sets them apart is how fast each one learns about new blocks and what its peers can do to it. Our node's height, next to the network's, is always on Network and mining.

More in Network and mining

See all 20 articles in Network and mining →

Last updated: November 11, 2026