How Could a Bitcoin Core Bug Bring Mining Operations to a Standstill?
The most consequential vulnerability, CVE-2025-62861, affected Bitcoin Core versions 28.0 through 28.2 and 29.0 through 29.1. Rated high severity, the bug affected transaction handling during blockchain reorganizations and could leave mining nodes unable to build valid block templates.
The issue centered on version 3 transactions, commonly known as TRUC transactions, which are subject to specialized mempool restrictions. During a chain reorganization, Bitcoin Core could mistakenly evict transactions but retain transactions that depended on them, creating inconsistencies in its transaction pool.
The effects could be especially troublesome for miners. Affected nodes might fail block template validation, effectively stopping them from generating new mining work until restarted. Mining equipment could keep hashing outdated templates, potentially losing transaction fees and operating less efficiently.
Security researcher Niklas Goegge reported the bug on Sept. 26, 2025. Developer Greg Sanders later introduced a fix, merged Oct. 2, to prevent the problematic eviction of transactions during reorganizations.
The fix was included in Bitcoin Core 30.0, 29.2, and 28.3 during October 2025. However, around the disclosure date, approximately 9% of reachable nodes were still advertising vulnerable versions.
What Were the Other Two Bitcoin Core Security Vulnerabilities?
The second vulnerability, CVE-2025-62859, was rated medium severity and involved maliciously crafted compact blocks. An attacker could exploit the improper handling of modified transaction witnesses to repeatedly delay block downloads. In certain network conditions, including compromised high-bandwidth peer connections, the disruption could continue indefinitely.
Researcher Eugene Siegel found the weakness in April 2025. Gregory Sanders developed a fix, which was included in Bitcoin Core versions 30.0 and 29.2.
CVE-2025-62860 involved a separate issue with inbound Tor connections and trusted-peer permissions. If operators used Bitcoin Core’s optional -whitelist setting to include their Tor daemon’s address, incoming connections could mistakenly receive privileges meant for trusted peers.
These exemptions weakened some denial-of-service safeguards and privacy protections. Bitcoin Core said thousands of reachable mainnet nodes could be affected, although standard configurations remained safe.
Why Did Bitcoin Core Wait Until November to Disclose the Flaws?
The announcements on Nov. 10 followed Bitcoin Core’s established disclosure schedule. Developers withheld technical details until the final vulnerable major release line, 29.x, reached end of life on Oct. 27, 2026. Unlike three AI-assisted vulnerability disclosures published on Oct. 28, these issues went through the conventional embargo process.
Importantly, none of the vulnerabilities allowed bitcoin theft, unauthorized coin creation, or consensus failure, and no exploitation was reported. The mining vulnerability required specific reorganization conditions, so its consequences were limited to affected operators rather than Bitcoin itself.
For bitcoin miners and node administrators, the distinction is important. Maintaining software remains essential even when vulnerabilities cannot compromise funds. The episode shows how seemingly obscure transaction-handling bugs can cause real operational problems without threatening the network’s underlying consensus.
Add A Comment
Comments are closed.