November 11, 2026

Bitcoin Core Discloses Three Patched Security Vulnerabilities Impacting Mining Operations, Block Processing, and Tor Connections

Bitcoin Core has officially disclosed three security vulnerabilities on November 10, 2026, a package that includes a high-severity defect capable of disrupting mining operations alongside two additional weaknesses affecting block processing and Tor network connections. Although developers successfully patched these software flaws in October 2025, their technical specifications and associated Common Vulnerabilities and Exposures identifiers were kept strictly confidential until the embargo expiration.

The delayed disclosure aligns with standard coordinated vulnerability disclosure practices within the Bitcoin development community, designed to give node operators and mining infrastructure administrators sufficient time to upgrade their software before malicious actors can weaponize the underlying source code. While the disclosure sheds light on significant software engineering challenges within the world’s leading cryptocurrency network, developers have confirmed that none of the three flaws permitted direct bitcoin theft, unauthorized coin creation, or a complete consensus failure, and no active exploits were reported in the wild prior to the public announcement.

How Could a Bitcoin Core Bug Bring Mining Operations to a Halt?

The most consequential vulnerability among the trio, formally identified as CVE-2025-62861, impacted Bitcoin Core versions 28.0 through 28.2 as well as versions 29.0 through 29.1. Classified as a high-severity defect, the issue centered on complex transaction handling procedures during blockchain reorganizations, a phenomenon that occurs when competing chains resolve and nodes must switch to the heavier valid chain. Under specific conditions, this defect could leave mining nodes entirely unable to construct valid block templates, creating severe operational bottlenecks for industrial mining facilities.

At the heart of the problem were version 3 transactions, widely referred to in the development ecosystem as TRUC transactions. These specialized transactions operate under distinct mempool restrictions designed to improve transaction relay efficiency and prevent certain types of fee-sniping and replacement attacks. However, during a blockchain reorganization, Bitcoin Core could incorrectly evict specific transactions while retaining dependent transactions, thereby creating internal inconsistencies within its local transaction pool.

For professional miners, the downstream consequences of this internal inconsistency were particularly troublesome. Affected nodes could fail critical block template validation checks, effectively preventing mining hardware from generating fresh mining work until the node software was manually or automatically restarted. While the mining equipment itself might continue hashing, it could easily end up working on outdated templates, potentially forfeiting valuable transaction fees and significantly reducing overall operational efficiency during a crucial window of network activity.

Security researcher Niklas Goegge originally reported the software defect to the Bitcoin Core security response team on September 26, 2025. Following the report, developer Greg Sanders engineered a targeted software correction that prevented the problematic transaction eviction behavior during blockchain reorganizations. This vital remedy was subsequently integrated into Bitcoin Core versions 30.0, 29.2, and 28.3 throughout October 2025. Despite the long window since the patch release, network telemetry around the public disclosure date indicated that approximately 9% of reachable public nodes were still advertising vulnerable versions, underscoring the persistent challenge of achieving comprehensive software updates across a decentralized ecosystem.

What Were the Other Two Bitcoin Core Security Vulnerabilities?

Alongside the mining-related defect, the security disclosures detailed two other technical challenges that had similarly undergone confidential patching. The second vulnerability, designated as CVE-2025-62859, carried a medium-severity classification and involved the handling of maliciously constructed compact blocks. An attacker capable of exploiting improper validation logic regarding altered transaction witnesses could repeatedly delay block downloads across the peer-to-peer network. Under particular network conditions, including scenarios involving compromised high-bandwidth peer connections, this artificial interference could theoretically continue indefinitely, degrading network propagation speeds.

Researcher Eugene Siegel identified this particular weakness in April 2025. Gregory Sanders once again stepped in to develop the necessary software correction, which was successfully merged and distributed to users via Bitcoin Core versions 30.0 and 29.2.

Meanwhile, CVE-2025-62860 exposed an entirely different class of problem involving inbound Tor connections and trusted-peer administrative permissions. When node operators configured Bitcoin Core’s optional whitelist setting to include their local Tor daemon’s address, incoming connections could mistakenly inherit broad privileges intended exclusively for trusted peers. Those unintended exemptions weakened specific denial-of-service safeguards and privacy protections inherent in the node architecture. Bitcoin Core indicated that thousands of reachable mainnet nodes were potentially affected by this configuration quirk, although standard out-of-the-box configurations without the specific whitelist parameter remained entirely safe from exploitation.

Why Did Bitcoin Core Wait Until November to Disclose the Flaws?

The November 10 announcements followed Bitcoin Core’s established disclosure schedule, which prioritizes network security by withholding granular technical details until vulnerable major release lines reach their official end-of-life status. In this case, developers held back the specifics until the 29.x release line officially reached end-of-life status on October 27, 2026. Unlike three separate AI-assisted vulnerability disclosures published by the project on October 28, these three issues followed the conventional, human-driven embargo process that has long governed core cryptographic infrastructure maintenance.

The distinction between consensus-breaking bugs and operational software defects remains a critical metric for bitcoin miners and node administrators. Software maintenance and timely patching remain vital operational necessities even when discovered vulnerabilities cannot directly compromise user funds or alter monetary policy rules. The episode serves as a notable reminder of how seemingly obscure transaction-handling defects can create tangible operational headaches for infrastructure providers without ever threatening the broader network’s underlying economic consensus.