Bitcoin Core discloses Tor bug that gave thousands of nodes trusted-peer rights

Bitcoin Core shipped a batch of security disclosures on Nov. 10, led by CVE-2025-62860, a medium-severity Tor flaw that handed incoming Tor connections the rights reserved for trusted peers on thousands of reachable nodes. Those privileges wiped out defenses against spam and safeguards against leaking private information. The write-ups landed only after the final affected release series, 29.x, hit end of support on Oct. 27.

The flaw grew out of how the software identified Tor traffic. Incoming Tor peers showed up under the IP address of the Tor software itself, usually running on the same computer or local network. When that address matched a range set through the optional -whitelist setting, outside connections inherited trusted-peer permissions, which strip out denial-of-service limits and privacy leak protections. Vendors that bundled Bitcoin Core alongside Tor with matching whitelist ranges left thousands of reachable mainnet nodes accepting every incoming Tor connection with those privileges, the developers said. Nodes that never enabled the non-default setting were untouched.

Martin Zumsande and Antoine Poinsot found the bug and reported it on Sept. 12, 2025. Zumsande's fix, merged Sept. 17, cut incoming onion connections out of whitelist permissions, noting that Tor connections never reveal a peer's actual network address, so address-based matching was pointless. Poinsot then notified affected software providers two days later. Bitcoin Core 30.0 carried the patch on Oct. 10, version 29.2 followed on Oct. 14, and the advisory lists 28.3 and later minor releases as patched too.

The second advisory, CVE-2025-62861, earned a high-severity rating and covered versions 28.0 through 28.2 and 29.0 through 29.1. It bit during chain reorganizations, when transactions from disconnected blocks flow back into the mempool. Version 3, or TRUC, rules normally cap relationships between unconfirmed transactions and are meant to be skipped during a reorg, but a transaction replacement rule stayed active, letting a restored transaction disappear while dependents stuck around and leaving an inconsistent mempool. With those inputs missing, a mining node's proposed block template flunked its validity check, and template creation stayed dead until a restart reloaded the mempool. Niklas Goegge reported it on Sept. 26; developer Greg Sanders noted the bypass argument for skipping TRUC checks was never actually checked, and the correction merged Oct. 2.

A third advisory, CVE-2025-62859, rates medium and targets compact blocks, the bandwidth-saving method nodes use to relay blocks. A malicious peer that announced a compact block first could get a victim to request the full block from that same peer, then sit through a 10-minute timeout triggered by a failed check for altered transaction witness data. An attacker controlling all three of a victim's high-bandwidth peers could repeat the stall indefinitely, and nodes running with -blocksonly were another configuration where repeated stalling was possible. Eugene Siegel reported it on April 28, 2025.

Bitcoin Core's disclosure policy normally keeps medium- and high-severity details under wraps until two weeks after the last affected release dies. An October policy change opened a faster lane for flaws that are easy to rediscover, including ones surfaced by a simple AI prompt, as crypto.news previously reported. June's 31.1rc1 release candidate patched a PrivateBroadcast privacy flaw that could expose IP addresses. In May, developers disclosed a script interpreter vulnerability where a specially crafted block could remotely crash vulnerable nodes, with the fix shipped in Bitcoin Core 29.0 in April 2025.