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.

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.

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.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到[email protected]，本平台相关工作人员将会进行核查。