Bitcoin Core patches three flaws, including a mining-blocking bug

Bitcoin Core disclosed three security vulnerabilities on Tuesday, including a high-severity flaw that could stop affected mining nodes from building valid block templates after a chain reorganization. All three fixes shipped before the disclosure: version 30.0 on Oct. 10, 2025, and version 29.2 on Oct. 14, 2025.

The three advisories, by identifier and severity:

• CVE-2025-62861 — high severity, mining templates. Affects versions 28.0 through 28.2 and 29.0 through 29.1. Reported by Niklas Goegge on Sept. 26, 2025.
• CVE-2025-62859 — medium severity, block processing delay. Reported by Eugene Siegel in April 2025, the earliest of the three submissions.
• CVE-2025-62860 — medium severity, Tor whitelist permissions. Reported in September 2025.

What breaks inside a mining node

The high-severity flaw sits in Bitcoin Core's TRUC "sibling eviction" rules, which the software still applied to transactions returning to the mempool after a reorganization. The code could evict a transaction without removing its descendants, leaving mempool state inconsistent. Affected miners had to restart their node before they could create valid block templates again.

Restart is a blunt remedy for a continuous operation: a node that cannot assemble a template cannot mine, and no pool can bid on a block without one. The advisory names no pool, miner or share of hash power affected, and it does not quantify how many operators ran the vulnerable versions. For any node still on 28.x or 29.0/29.1, the remedy is a version upgrade rather than another restart.

How a peer could stall block processing

The medium-severity CVE-2025-62859 let a malicious peer exploit witness malleability in compact blocks and delay block processing by up to 10 minutes. The advisory says the attack could be repeated indefinitely against nodes running in "-blocksonly" mode, and against nodes where the attacker controlled all three high-bandwidth peers.

Those preconditions narrow the exposure considerably: an indefinite stall requires either a mode that skips full block validation or control of a node's entire high-bandwidth peer set, and no operator is named as having observed the attack. Treat it as a resilience problem for mining and routing infrastructure rather than a proven live exploit.

Who inherited Tor whitelist rights

The third flaw, CVE-2025-62860, granted whitelist permissions to incoming Tor peers when the IP address of their proxy fell inside a configured range. It affected nodes running the optional "-whitelist" setting whose IP range included the Tor proxy.

Bitcoin Core said "thousands" of reachable mainnet nodes had been whitelisting incoming Tor connections, which removes certain denial-of-service limits and privacy protections. Nodes without the non-default setting were not affected. The figure is the developers' own approximation: no node count was published, and no independent measurement of the exposed population exists.

What the end-of-life date leaves behind

According to the advisories, the last vulnerable Bitcoin Core version went end of life on Oct. 27. That closes the supported line for anyone still running the affected releases.

The disclosure sequence matters for risk accounting. Bitcoin Core fixed each flaw in October 2025 and published the advisories publicly on Tuesday, so operators upgraded before they could read the explanation. The Block reported in May on a separate high-severity memory safety vulnerability that developers had also patched before publicly disclosing it, which points to a house pattern of fix first and explain later.

What operators should check now

Node operators running the "-whitelist" option should review whether their configured IP ranges overlap the address of a Tor proxy sitting in front of incoming peers; nodes without that non-default setting carry no exposure from this flaw. Miners should confirm their node version against 30.0 or 29.2 and treat the TRUC sibling-eviction fix as the gating item for post-reorg template creation.

With the vulnerable branch now end of life and the patches shipping in 30.0 and 29.2, the next chain reorganization becomes the first live test of the corrected logic, and further advisories will likely arrive in the same order: fix, then explanation.