Bitcoin Core details three patched flaws, including mining halt

Bitcoin Core disclosed three previously patched vulnerabilities on 10 November, including a high-severity bug that could stop an affected mining node from constructing blocks. The other two disclosures concern delayed block processing and excessive permissions for incoming Tor connections. Their fixes were released in 2025.

The reports concern different parts of the software: the pool of waiting transactions, communication between nodes, and permissions for trusted network peers. For operators, the useful questions are which version is running and which network settings are enabled. Each advisory gives its own affected range and repair history.

A reorganisation could leave a miner unable to build blocks

CVE-2025-62861, rated High by Bitcoin Core, affects versions 28.0–28.2 and 29.0–29.1. The bug appears when a chain reorganisation causes transactions from disconnected blocks to be put back into the mempool, the node’s collection of transactions awaiting confirmation.

Bitcoin Core applies special relay rules to version-three transactions, called TRUC transactions. Those rules restrict the relationships between unconfirmed transactions. A valid confirmed block can contain a more complicated arrangement, so restoring its transactions after a reorganisation needs different handling.

The defective code applied a replacement rule during that restoration. It could remove a transaction while leaving transactions that depended on it in the mempool. When the affected mining node assembled a proposed block, its own validity check failed. Bitcoin Core says restarting the node reloaded a consistent mempool and restored block construction; the permanent repair changes the restoration logic.

The fix appeared in Bitcoin Core 30.0, followed by backports to 29.2 and 28.3. Niklas Goegge discovered and responsibly disclosed the issue. The advisory records public disclosure on 10 November 2026, after the vulnerable 29.x branch reached the end of its support life.

A malicious peer could delay block processing

CVE-2025-62859 is a Medium-severity defect in compact-block handling, repaired in versions 29.2 and 30.0. Compact blocks reduce the data nodes exchange by using transactions the recipient already knows. The vulnerable implementation cleared part of its download state before completing a check involving witness data, which holds transaction signatures and related information.

An attacker could exploit a failed reconstruction to make the victim request the full block from the same peer and wait for a timeout. Under the conditions described by the developers, that delay could be repeated. Those conditions include control of the victim’s three high-bandwidth peers or the victim using the block-only configuration.

The operational consequence is delayed knowledge of new blocks. Nodes and mining infrastructure depend on receiving and processing those blocks promptly to follow the chain’s current tip. Eugene Siegel reported the defect, and the advisory records its repair and the later public disclosure separately.

Tor traffic could inherit trusted-peer privileges

CVE-2025-62860, also rated Medium, affects nodes using a non-default IP-based whitelist that matches their Tor daemon’s address. Incoming Tor connections appear locally to come from that daemon. The old permission check could therefore treat incoming onion-network peers as trusted connections.

Whitelist permissions relax some denial-of-service limits and privacy protections for peers an operator intends to trust. The fixed implementation handles onion-bound incoming connections separately when applying IP-based whitelist rules. Operators’ combination of software version, Tor setup and whitelist configuration determines whether this disclosure applies to their installation.

The repair history gives operators a concrete check

The November disclosures document repairs already incorporated into later Bitcoin Core releases. The version numbers in the table identify the original repairs; an operator maintaining a node should use the project’s currently supported release line and check the relevant configuration alongside its version history.

The three reports show how availability and permission errors can sit outside transaction-signature verification itself. Reliable mining depends on a consistent local transaction pool, timely block delivery and correct handling of peers. The disclosures give administrators specific components and release histories to check for each of those responsibilities.