Key Takeaways
- Bitcoin Core disclosed three previously patched vulnerabilities this week, including one capable of interrupting mining operations.
- The most serious defect could prevent affected nodes from producing valid block templates following a blockchain reorganization.
- Thousands of nodes faced potential exposure to a separate Tor configuration flaw, although default installations were unaffected.
How Could a Bitcoin Core Bug Bring Mining Operations to a Halt?
The most consequential vulnerability, identified as CVE-2025-62861, affected Bitcoin Core versions 28.0 through 28.2 and 29.0 through 29.1. Classified as high severity, the defect involved transaction handling during blockchain reorganizations, potentially leaving mining nodes unable to construct valid block templates.
At its center were version 3 transactions, commonly called TRUC transactions, which operate under specialized mempool restrictions. During a chain reorganization, Bitcoin Core could incorrectly evict transactions while retaining dependent transactions, creating inconsistencies within its transaction pool.
For miners, the consequences were particularly troublesome. Affected nodes could fail block template validation, effectively preventing them from generating fresh mining work until restarted. Mining equipment could continue hashing outdated templates, potentially forfeiting transaction fees and reducing operational efficiency.
Security researcher Niklas Goegge reported the defect on Sept. 26, 2025. Developer Greg Sanders subsequently introduced a correction, merged Oct. 2, that prevented the problematic transaction eviction behavior during reorganizations.
The remedy appeared in the software Bitcoin Core 30.0, 29.2, and 28.3 throughout October 2025. Nevertheless, approximately 9% of reachable nodes continued advertising vulnerable versions around the disclosure date.
What Were the Other Two Bitcoin Core Security Vulnerabilities?
The second vulnerability, CVE-2025-62859, carried a medium-severity classification and involved maliciously constructed compact blocks. An attacker could exploit improper handling of altered transaction witnesses to repeatedly delay block downloads. Under particular network conditions, including compromised high-bandwidth peer connections, the interference could continue indefinitely.
Researcher Eugene Siegel identified the weakness in April 2025. Gregory Sanders developed the correction, which reached Bitcoin Core versions 30.0 and 29.2.
Meanwhile, CVE-2025-62860 exposed an entirely different problem involving inbound Tor connections and trusted-peer permissions. When operators configured Bitcoin Core’s optional -whitelist setting to include their Tor daemon’s address, incoming connections could mistakenly inherit privileges intended for trusted peers.
Those exemptions weakened certain denial-of-service safeguards and privacy protections. Bitcoin Core indicated that thousands of reachable mainnet nodes were potentially affected, although standard configurations remained safe.
Why Did Bitcoin Core Wait Until November to Disclose the Flaws?
The Nov. 10 announcements followed Bitcoin Core’s established disclosure schedule. Developers withheld technical details until the final vulnerable major release line, 29.x, reached end-of-life status on Oct. 27, 2026. Unlike three AI-assisted vulnerability disclosures published Oct. 28, these issues followed the conventional embargo process.
Importantly, none permitted any bitcoin theft, unauthorized coin creation, or consensus failure, and no exploitation was reported. The mining vulnerability required specific reorganization conditions, meaning its consequences were confined to affected operators rather than Bitcoin itself.
For bitcoin miners and node administrators, the distinction matters. Software maintenance remains essential even when vulnerabilities cannot compromise funds. The episode illustrates how seemingly obscure transaction-handling defects can create tangible operational problems without threatening the network’s underlying consensus.
