Bitcoin Core on 10th November, 2026 disclosed CVE-2025-62861, a high-severity bug that could stop mining nodes from building valid block templates after a chain reorganization. The project disclosed two medium-severity flaws alongside it, and fixes for all three shipped in October 2025.
Key Facts
- CVE-2025-62861, the high-severity bug, affects Bitcoin Core versions 28.0 to 28.2 and 29.0 to 29.1.
- Mining nodes hit by the bug could not build a valid block template until the operator restarted them.
- Niklas Goegge reported the flaw on 26th September, 2025, and Bitcoin Core 30.0 shipped a fix 14 days later.
- Two medium-severity flaws, CVE-2025-62859 and CVE-2025-62860, affected compact block handling and nodes whose whitelist covered their Tor proxy.
A reorg could leave miners unable to build blocks
TRUC transactions, the version 3 format defined in BIP 431, face extra mempool rules. Each one may have at most one unconfirmed ancestor and at most one unconfirmed descendant. Those limits apply to relay policy only, so a valid block can still contain a TRUC parent with several children.
Version 28.0 added “sibling eviction” to police that descendant limit. When a new transaction would give a TRUC parent a second unconfirmed child, Bitcoin Core treats the existing child as a replacement candidate. If the newcomer pays enough, replace-by-fee rules let the node evict the older child.
The trouble started during reorgs. Bitcoin Core re-adds transactions from disconnected blocks with a bypass_limits flag set to true. That flag exists to restore them faithfully, skipping mempool anti-DoS and topology checks. The sibling-eviction branch ignored that flag, so TRUC enforcement kept running while confirmed transactions flowed back into the mempool.
THE BLOCK: Bitcoin Core disclosed three previously patched security vulnerabilities, including a high-severity flaw that could prevent affected mining nodes from creating block templates. bitcoin:native The other two flaws could stall block processing and improperly grant trusted permissions to incoming Tor connections.
— The Block (@TheBlockCo) November 11, 2026
A reorg can restore a topology that blocks allow but the mempool forbids. With eviction still active, the node could drop a restored transaction but keep its descendants. The mempool then held transactions spending outputs that no longer existed. As a result, the assembled template failed its validity check.
The Bitcoin Core advisory states that “a node that performed such a reorg cannot produce blocks until it is restarted.” A restart reloads the mempool in a consistent state.
Greg Sanders opened PR #33504 on 09/29/2025 to gate the TRUC checks on bypass_limits, which stops sibling eviction during reorg re-addition. The change reached master on 10/02/2025 and was backported to the 28.x, 29.x and 30.x branches. The Bitcoin Core 30.0 release carried it on 10/10/2025, with 29.2 following on 10/14/2025 and 28.3 on 10/17/2025.
Two medium bugs hit compact blocks and Tor peers
Eugene Siegel reported CVE-2025-62859 in April 2025, making it the earliest of the batch. A malicious peer could exploit witness malleation in compact blocks to delay block processing by up to 10 minutes. The advisory says an attacker could repeat the delay indefinitely against -blocksonly nodes, or where the attacker controlled all three high-bandwidth peers.
CVE-2025-62860 is a configuration trap. Incoming Tor peers could receive whitelist permissions when their proxy’s IP address fell inside a range set with the optional -whitelist setting. Bitcoin Core said “thousands” of reachable mainnet nodes had been whitelisting incoming Tor connections, removing certain denial-of-service limits and privacy protections. Nodes without that non-default setting stayed unaffected.
Operators who use -whitelist should check whether any configured range covers their Tor proxy’s address. Bitcoin Core 30.0 shipped fixes for all three bugs, so upgrading helps reduce risk across the whole batch. All three also carry 2025 identifiers despite a 2026 publication date, a lag worth remembering when reading CVE statistics by year.
Disclosure landed 13 months after the fixes
Goegge’s report reached the Bitcoin Core security mailing list, and a fixed release followed within two weeks. The public write-up then waited for the last vulnerable branch, 29.x, to reach end of life on 27th October, 2026. Publication came two weeks after that.
That sequencing gave operators about 13 months with patched builds before anyone could read how the bug worked. It also means a node that skipped every upgrade since 2025 now runs a publicly documented flaw on an unsupported branch. The batch follows a separate high-severity memory safety flaw, covered by The Block in May, that developers also patched ahead of public disclosure.
The TRUC bug hit block production itself, a quieter failure than the thefts tracked in cybersecurity in cryptocurrency statistics. The advisories document the mechanism and the fix dates. They leave these questions open:
- Did any mining node actually hit the TRUC bug in production before the fix shipped?
- How many reachable nodes still run 28.0 to 28.2 or 29.0 to 29.1?
- How many of the Tor-whitelisting nodes have since upgraded or changed their configuration?
- Could an attacker deliberately produce the reorg topology that triggers sibling eviction?
What’s Next?
Miners who saw template creation fail after a reorg on an affected version can clear that state with a restart, which reloads the mempool. Only an upgrade removes the bug.
For node operators, the check comes down to a version string. Anything from 28.0 to 28.2 or 29.0 to 29.1 still carries the template bug. The patched releases 28.3, 29.2 and 30.0 have all been available since 17th October, 2025.
