The Bitcoin Core project disclosed three security vulnerabilities on Tuesday 10 November 2026, all of them fixed more than a year ago. The most serious, CVE-2025-62861, is rated High: after a chain reorganisation it could leave a blockchain and earns a reward, which makes rewriting history very expensive.">mining node unable to build block templates until someone restarted it. A second, CVE-2025-62860, gave inbound Tor connections trusted status on nodes that used a non-default whitelist setting, and the advisory says thousands of reachable mainnet nodes were in that situation. The third, CVE-2025-62859, let a hostile peer stall block processing. Both of those are rated Medium.
The fixes shipped in Bitcoin Core 30.0 on 10 October 2025, then in 29.2 on 14 October and in 28.3 (for two of the three) a few days later. Any node on 29.2, 30.0 or a newer release already has them. The advisories on bitcoincore.org mention no exploitation, and Decrypt reported none. None of the three bugs can move or steal coins; at worst they stop a node from doing its job for a while.
People who hold bitcoin on an exchange or in a phone wallet have nothing to do. The audience for these advisories is narrower: miners and mining pools, businesses that run their own nodes, and the many hobbyists running a plug-and-play node box at home, which is where the Tor bug did most of its harm.
The release notes of Bitcoin Core 32.1, published on 27 October, announced that three Medium and High issues fixed in 30.0 would be disclosed two weeks later, as our report on Bitcoin Core’s first AI-found bugs noted at the time. This batch is separate from those October bugs, which an automated scan found and which went public at once under the fast lane for flaws that are easy to discover. These three were reported by people between April and September 2025 and sat under the ordinary embargo.
Three Bitcoin Core vulnerabilities, one disclosure date
The three advisories went up together because they share the same last vulnerable line, 29.x, which reached its end of life on 27 October 2026. Each is summed up below.
| CVE | What it does | Severity | Affected versions | Fixed in | Reported by (date) |
|---|---|---|---|---|---|
| CVE-2025-62861 | Halts block template creation after a reorg | High | 28.0 to 28.2, 29.0 to 29.1 | 28.3, 29.2, 30.0 | Niklas Goegge (26 Sep 2025) |
| CVE-2025-62860 | Gives inbound Tor peers whitelist permissions | Medium | Before 28.3, 29.2 and 30.0, with -whitelist set | 28.3, 29.2, 30.0 | Martin Zumsande and Antoine Poinsot (12 Sep 2025) |
| CVE-2025-62859 | Stalls block processing via witness malleation | Medium | Before 29.2 and 30.0 | 29.2, 30.0 | Eugene Siegel (28 Apr 2025) |
Only CVE-2025-62861 carries the High label. One detail differs between the pages: the CVE-2025-62861 advisory dates the 28.3 release to 17 October 2025, the CVE-2025-62860 advisory to 20 October.
The high-severity bug: a reorg could freeze a miner’s block templates
CVE-2025-62861 sits in the mempool, the waiting room where a node keeps unconfirmed transactions, and it involves a newer transaction type. TRUC transactions, short for Topologically Restricted Until Confirmation and defined in BIP 431, are version 3 transactions with tight limits on their unconfirmed family: a TRUC parent may have only one unconfirmed child. Version 28.0 added “sibling eviction”, which lets a new child that pays enough fees replace the existing one.
Those limits are mempool policy, not consensus rules. A valid block can contain transaction families that a node’s mempool would refuse. That matters during a reorganisation, when the node drops the last block or two of its chain in favour of a longer branch and puts the transactions of the dropped blocks back into its mempool. It does so with a flag, bypass_limits, that is meant to skip policy checks for exactly that reason.
The sibling-eviction code ignored the flag. During a reorg it could evict a transaction that was being restored while leaving that transaction’s descendants in the mempool. Those descendants then spent outputs that no longer existed anywhere.
The advisory is about what this did to miners. When the node assembles a block template, the list of transactions a smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool hands to its machines, it runs a validity check on the result. With orphaned descendants inside, the check failed, and the node could not produce blocks until it was restarted, since a restart reloads a consistent mempool. One-block reorgs do occur on bitcoin, but the reorganised blocks also had to contain the right TRUC transactions.
Niklas Goegge reported the problem to the Bitcoin Core security mailing list on 26 September 2025. Greg Sanders opened the fix, pull request #33504, three days later; it makes the TRUC checks respect bypass_limits, was merged on 2 October and was backported to the 29.x, 30.x and 28.x branches between 3 and 7 October. Only versions 28.0 to 28.2 and 29.0 to 29.1 were affected, since sibling eviction did not exist before 28.0.
A compact block trick that could stall a node
CVE-2025-62859 targets compact block relay, the method nodes use to pass new blocks around quickly. Instead of sending a full block, a peer sends a short summary, and the receiving node rebuilds the block from transactions it already has in its mempool. A node picks up to three peers as “high-bandwidth” relays that push compact blocks to it without being asked.
In affected versions, the node cleared its download state for a compact block right after rebuilding it, but before checking whether the block’s witness data had been tampered with (malleated). If that check failed, the node fell back to asking the same peer for the full block, with a 10-minute timeout. A malicious peer that was first to announce a block could therefore hold the victim’s block processing for up to ten minutes. According to the advisory, the attacker could repeat this without end if it controlled all three of the victim’s high-bandwidth peers, or if the victim ran in -blocksonly mode.
Eugene Siegel reported the bug on 28 April 2025. Gregory Sanders opened the fix, pull request #32646, on 30 May; it was merged on 30 June and backported to the 29 line on 12 September. The advisory lists fixes only in 29.2 and 30.0, and names no fixed 28.x release, so the safe reading is that 28.x and older lines stay exposed to this one.
The Tor whitelist bug gave strangers trusted status on thousands of nodes
CVE-2025-62860 is the one most likely to concern home node runners. Bitcoin Core has an option, -whitelist, that grants special permissions to peers connecting from given IP addresses. Whitelisted peers are treated as trusted: the node lifts some of its denial-of-service limits for them and some of the protections meant to stop information leaking to peers that could use it to spy on transactions. It is off by default and meant for machines the operator controls.
The trouble is how Tor connections look from the inside. A node reachable as a Tor hidden service receives every inbound Tor connection from the local Tor daemon, so they all appear to come from the same address, usually on the same machine or network. If the whitelist covered that address, every stranger arriving over Tor inherited the trusted status.
According to the advisory, popular vendors shipped Bitcoin Core bundled with a Tor daemon and set -whitelist to the range of that daemon’s address, and client software run alongside Tor commonly required the option too. That is how thousands of reachable mainnet nodes ended up whitelisting all incoming Tor connections. The advisory names no vendor, so users of packaged home nodes that bundle Tor should check rather than assume.
Martin Zumsande and Antoine Poinsot reported the issue on 12 September 2025. The fix, pull request #33395, opened on 15 September, was merged and backported on 17 September; in fixed versions, inbound connections received on an onion bind are never whitelisted, whatever the setting says. That same day Poinsot told Luke Dashjr, maintainer of Bitcoin Knots, a separate client derived from Bitcoin Core, and on 19 September he told several affected software providers. The fixed releases followed in October 2025.
How many nodes still report affected versions
Network counts give an idea of how far the fixes have spread, with limits. In the Bitnodes snapshot of 11 November 2026 at 17:01 UTC (block height 975,450), Bitnodes listed 20,111 reachable nodes. Their versions come from user agents the nodes report about themselves, which can be changed or faked, and nodes that accept no incoming connections are not counted at all. By Coindaro’s count of that file, 18,048 of the 20,111 announced a plain Bitcoin Core user agent, 2,001 a Knots one and 62 something else.
| Bitcoin Core user agents in the snapshot | Nodes | Share of Core agents |
|---|---|---|
| In the CVE-2025-62861 ranges (28.0 to 28.2, 29.0 to 29.1) | 1,850 | about 10.3% |
| Below 29.2 (CVE-2025-62859, upper bound) | 3,913 | about 21.7% |
| Below the CVE-2025-62860 fix lines | 3,861 | about 21.4% |
| Most common version, 32.1.0 | 4,567 | about 25.3% |
Those shares overstate the real exposure. The High bug only bites nodes that build block templates, and how many mining nodes still run an affected version cannot be seen from outside: pool infrastructure is rarely reachable. The Tor bug only touched nodes with -whitelist set, a share no crawler measures. The 1,850 figure is dominated by 28.1.0 (578 plain agents and 311 more from a FutureBit build), 29.0.0 (463), 28.0.0 (231) and 29.1.0 (160).
Knots, at 2,001 reachable nodes and mostly on its 29.3 release, is a different client, and the Core advisories say nothing about its status. The broader problem of nodes running unmaintained lines was covered in our count of Bitcoin Core nodes on end-of-life versions, which found about 44% of Core agents in an 18 October crawl outside supported lines.
What node operators should check now
The supported lines today are 30.x, 31.x and 32.x. Their latest releases, 32.1 (27 October) and 30.4 and 31.2 (28 October), also carry the fixes for the October advisories. What to do:
- Check the version your node reports (bitcoin-cli getnetworkinfo shows it, and most node dashboards display it). Anything older than 30.0 is on a line that gets no more fixes.
- Upgrade to 30.4, 31.2 or 32.1, downloaded from bitcoincore.org, and verify the signatures before installing.
- If you run a packaged node with Tor, update the package and look at the bitcoin.conf it generates: a -whitelist range that includes the Tor daemon’s address should not be there on older builds.
- Mining pools and solo miners whose node stopped producing templates after a reorg on an affected version should restart it, then upgrade.
For readers setting up a node for the first time, our step-by-step guide to running a Bitcoin node covers downloads, signature checks and updates.
Why the advisories waited 13 months
Under the project’s disclosure policy, each bug gets a severity. Low-severity issues are disclosed two weeks after the fix is released. Medium and High issues stay private until two weeks after the last release line containing the bug reaches its end of life, roughly a year after the fixing major version first shipped. Critical issues would most likely get an ad hoc procedure. The 13-month gap is not unusual: CVE-2024-52911, a High-severity crash bug fixed in 29.0 in April 2025, was disclosed on 5 May 2026.
The trade-off is visible in this batch. The fix for the Tor bug was public code from September 2025, readable by anyone who looked at the pull request, while the explanation of what it closed stayed private until this week. Operators who upgrade only when an advisory appears were covered by the delay but never told why. The October change, which publishes easy-to-find bugs with their fixes right away, moved part of the process in the other direction.
The next batch of this kind depends on the 30.x line, now the oldest maintained one. The project’s lifecycle page puts its end of life after the release of 33.0, and any Medium or High bug it still contains would be disclosed two weeks after that.