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.