Bitcoin Core on Tuesday, November 10, disclosed three security flaws it patched a year ago, including CVE-2025-62861, a high-severity bug that left mining nodes unable to build new blocks after a chain reorganization until the operator restarted them.

    CVE-2025-62861 affects Bitcoin Core 28.0 to 28.2 and 29.0 to 29.1. A reorg could corrupt the node’s mempool, the queue of unconfirmed transactions, so that every block template the node assembled failed its own validity check. Bitcoin Core rates the flaw High on its own four-level scale; the advisory carries no CVSS score.

    The project published two medium-severity advisories the same day. CVE-2025-62859 let a malicious peer stall a node’s block processing for 10 minutes at a time, and CVE-2025-62860 handed trusted-peer permissions to anonymous inbound Tor connections on nodes with a common non-default setting.

    All three are fixed in Bitcoin Core 30.0, released October 10, 2025, and in 29.2, released four days later. Nodes on 30.0 or newer were never exposed to the published details; nodes still on 28.x or older are, and those release lines no longer receive fixes.

    How CVE-2025-62861 Stops a Node From Mining

    The bug sits in Bitcoin Core’s handling of TRUC transactions, the “version 3” transaction type defined in BIP 431. A TRUC transaction may have at most one unconfirmed parent and one unconfirmed child in the mempool. That is a relay policy, not a consensus rule, so a valid block can legally contain a TRUC parent with several children.

    Bitcoin Core 28.0 added “sibling eviction”: when a new transaction would give a TRUC parent a second child, the node treats the existing child as a replacement candidate and evicts it if the newcomer pays enough.

    During a reorg, when the node abandons one or more blocks for a competing chain, it puts the transactions from the dropped blocks back into the mempool with a bypass_limits flag that is meant to skip policy checks. The sibling-eviction code did not check that flag. A reorg could therefore restore a parent with multiple children; sibling eviction would remove one of them, and that transaction’s descendants would remain, spending outputs that no longer existed.

    With the mempool in that state, block template creation fails, and a mining node has nothing valid to hand its hashers. According to the advisory, the node cannot produce blocks until it is restarted, which consistently reloads the mempool.

    Niklas Goegge reported CVE-2025-62861 to the Bitcoin Core security list on September 26, 2025. Greg Sanders opened the fix, PR #33504, three days later; it gates the TRUC checks on bypass_limits so sibling eviction no longer runs during a reorg. The fix was merged on October 2, 2025.

    Two Medium-Severity Flaws Hit Compact Blocks and Tor Peers

    CVE-2025-62859 involves compact blocks, the bandwidth-saving format peers use to announce new blocks. Affected nodes cleared their download state for a block after reconstructing it but before checking whether its witness data had been tampered with. If that check failed, the node asked the same peer for the full block and waited out a 10-minute timeout.

    A malicious peer that announced a block first could trigger the stall. The CVE-2025-62859 advisory says the attack can be repeated indefinitely if the attacker controls the victim’s three high-bandwidth peers, or if the victim runs with -blocksonly. Eugene Siegel reported the flaw on April 28, 2025, and PR #32646 fixed it.

    CVE-2025-62860 affects only nodes that set the -whitelist option, which lifts denial-of-service limits and privacy protections for trusted peers. Inbound Tor connections appear to come from the local Tor daemon’s address, so when the whitelisted range covered that address, every anonymous Tor peer was treated as trusted.

    The exposure was wide because popular node packages bundled Bitcoin Core with Tor and set -whitelist to match. Bitcoin Core said this led to “thousands of reachable mainnet nodes” whitelisting all inbound Tor connections. Martin Zumsande and Antoine Poinsot reported the issue on September 12, 2025; PR #33395 prevents whitelist permissions from being applied to inbound Tor peers. Poinsot also notified Bitcoin Knots maintainer Luke Dashjr and several affected software providers that month, according to the advisory.

    Why Bitcoin Core Waited a Year to Publish

    The 13-month gap is policy, not a delay. Under Bitcoin Core’s disclosure policy, medium- and high-severity bugs are published two weeks after the last affected release line reaches end of life. The 29.x line reached end of life on October 27, 2026, with the release of Bitcoin Core 32.1, and the advisories followed exactly two weeks later.

    The fixes themselves were public code changes in September and October 2025, merged without security labels. All three CVE IDs carry a 2025 prefix for that reason.

    Which Bitcoin Core Versions Have the Fixes

    The CVE-2025-62859 advisory lists fixes only in 30.0 and 29.2, so the final 28.x releases still carry the compact-block stall. The mining bug, CVE-2025-62861, does not exist before 28.0, the release that introduced sibling eviction.

    Old versions remain common. A network snapshot taken on October 18 found 3,671 of 8,422 self-reported Bitcoin Core peers, or 43.6%, on release lines that had already reached end-of-life, CryptoSlate reported. That count covers 28.x and older, predating the 29.x cutoff.

    Is CVE-2025-62861 Being Exploited?

    None of the three advisories report exploitation in the wild, and Bitcoin Core has not published proof-of-concept code for any of them.

    The CVE-2025-62861 advisory describes the trigger as a reorg that restores a transaction layout the mempool would normally reject. It does not say whether an attacker could cause such a reorg on demand or whether any miner lost blocks to the bug before the fix. Bitcoin Core also gives no rationale for the High rating, a category its policy reserves for bugs with significant impact on nodes or the network.

    None of the advisories describes theft of funds or a change to Bitcoin’s consensus rules. The stated impact is lost availability for CVE-2025-62861 and CVE-2025-62859, and weakened denial-of-service and privacy protections for CVE-2025-62860.

    What Node Operators and Miners Should Do Now

    Operators should run a maintained release: Bitcoin Core 32.1, 31.2, or 30.4 as of November 11, 2026, available from the Bitcoin Core download page. Bitcoin Core does not update itself, and the lifecycle page lists 29.x and all earlier versions as end-of-life.

    To check a running node, bitcoin-cli getnetworkinfo returns the version in its subversion field. Pool operators should also confirm the version of every node that serves block templates, not only the public-facing ones.

    For CVE-2025-62861, a restart restores block production on an affected node, but it does not prevent the next reorg from breaking the mempool again. For CVE-2025-62860, the advisory lists no workaround other than upgrading; operators of bundled node packages can review their -whitelist setting and check the permissions field in bitcoin-cli getpeerinfo to see which peers are considered trusted. No workaround is listed for CVE-2025-62859.

    Community Discussion

    Join the conversation. Ask questions, share solutions, and help others.

    Be the first to start the discussion!

    Leave a Comment Cancel reply