The high-severity flaw, disclosed on November 10 alongside two medium ones, left an affected node unable to produce a valid block template until it was restarted. The fixes shipped in October 2025, and the advisories waited until the last vulnerable release line lost support.
Bitcoin Core published three security advisories on November 10, and the most serious describes a bug that could leave a mining node unable to assemble a block. CVE-2025-62861, rated high severity, affected Bitcoin Core 28.0 through 28.2 and 29.0 through 29.1. On a node that processed a particular kind of chain reorganization, block template creation fails its own validity check, and the advisory says the node cannot produce blocks until it is restarted.
The fault sits in how the mempool handled TRUC transactions during a reorg. TRUC, the version 3 transaction type, is limited by mempool policy to at most one unconfirmed ancestor and one unconfirmed descendant. Those are relay policy rules rather than consensus rules, so a valid block can contain a TRUC parent with several children. Sibling eviction, added in version 28.0, removes an existing child when a new transaction gives the parent a second one and pays enough to satisfy replace-by-fee.
When a reorg takes place, transactions from the disconnected blocks are re-added to the mempool with a flag that bypasses those policy limits. The sibling-eviction branch was not gated on that flag. A reorg could therefore restore a set of transactions that TRUC policy forbids, sibling eviction could then remove one of the restored transactions while its descendants stayed behind, and the mempool was left holding transactions that spent outputs which, in the advisory's wording, no longer existed. Only a restart reloads the mempool consistently.
Niklas Goegge reported the bug to Bitcoin Core's security mailing list on September 26, 2025. Greg Sanders opened a fix three days later, it merged on October 2, and it was backported to the 28.x, 29.x and 30.x branches over the following week. Bitcoin Core 30.0 shipped with the fix on October 10, 2025, and 29.2 followed on October 14. The advisory does not say how many nodes ran an affected version, does not quantify how often a qualifying reorg occurred, and does not report any observed exploitation.
The second advisory is the only one of the three that puts a scale on its exposure. CVE-2025-62860, rated medium, concerns the non-default whitelist option, which an operator uses to grant trusted peers relief from some denial-of-service limits and privacy-leak mitigations. Connections arriving over Tor appear to Bitcoin Core as coming from the Tor daemon's own address, which usually sits on the same machine or local network. If that address fell inside a whitelisted range, the node extended whitelist permissions to every inbound Tor peer.
That configuration was not unusual. The advisory says popular vendors shipped Bitcoin Core bundled with a Tor daemon and set the whitelist option to match it, which left thousands of reachable mainnet nodes whitelisting all incoming Tor connections. It names no vendor and gives no count beyond thousands. Nodes that never set the option were never affected. Martin Zumsande and Antoine Poinsot reported the issue on September 12, 2025, and Poinsot notified the Bitcoin Knots maintainer Luke Dashjr on September 17 and other affected software providers two days after that.
The third flaw, CVE-2025-62859, also medium, let a peer stall a node's block processing. Affected versions cleared a compact block's download state after reconstructing the block but before checking it for witness malleation. When that check failed, the node fell back to requesting the block again from the same peer, subject to a ten-minute timeout. A peer that announces a compact block to its target first can use that gap to delay the target's processing, and the advisory says the delay could be repeated indefinitely against a node running in blocks-only mode, or against one whose three high-bandwidth peers the attacker controls. Eugene Siegel reported it in April 2025.
All three disclosures follow the same sequence. Each bug was reported in 2025 and fixed in the October 2025 releases. The 29.x series, the last line still in support that carried any of them, reached end of life on October 27 this year, and the advisories went out two weeks after that. Operators still running 29.1 or earlier now have public descriptions of three flaws in software they have not updated.
Bitcoin Core's mempool has changed substantially since the fixes landed. Version 31.0, released in April, replaced the software's original transaction queuing logic with a cluster-based design. No version in the 30.x or 31.x lines appears among the affected releases in any of the three advisories.
Other projects have handled disclosure differently. Cosmos Labs shipped a fix under a release note that named nothing, and attackers took about $5.7 million from six chains in the days that followed. BTCPay Server went the other way, disclosing a critical Lightning credential bug while it was being exploited and releasing the patch the same day.
The audience for the high-severity bug is narrower than for the other two. Assembling block templates is what a mining node does, and at scale that work sits with pool operators rather than with ordinary full nodes. Bitcoin's seven-day average hashrate climbed back above 1,000 exahashes per second in October, and the set of pools it is spread across narrowed on November 10, when Binance switched off its mining pool.
All three advisories point to the same remedy, which is to run a release that carries the fix. Bitcoin Core 30.0 and later carry all three. The 28.3 and 29.2 backports sit inside lines that no longer receive support.
