Bitcoin Core reveals Tor flaw that trusted thousands of nodes

The payment rail for your crypto. One card. Every chain. No KYC. Spend with Apple Pay or Google Pay in 180+ countries.

Bitcoin Core has disclosed a vulnerability that gave incoming Tor connections trusted permissions on thousands of nodes, removing some protections against spam and privacy leaks.

Summary

Thousands of reachable nodes granted incoming Tor connections permissions intended for trusted peers.
The medium-severity flaw affected certain whitelist configurations and was patched in October 2025.
A separate high-severity bug could stop affected mining nodes from creating valid block templates.

Bitcoin Core’s security disclosure, published Nov. 10, identifies the Tor issue as CVE-2025-62860. Developers released the details alongside two other vulnerabilities after the last affected release series, 29.x, reached the end of support on Oct. 27.

Bitcoin Core’s whitelist settings let Tor traffic bypass limits

According to the advisory, incoming Tor peers appeared to Bitcoin Core under the IP address of the Tor software, which usually ran on the same computer or local network. When that address matched a range configured through the optional -whitelist setting, outside connections received permissions intended for trusted peers.

Whitelisting removes various denial-of-service limits and safeguards against leaking private information. Popular vendors bundled Bitcoin Core with Tor and configured matching whitelist ranges, leaving thousands of reachable mainnet nodes accepting all incoming Tor connections with those privileges, the developers said.

Nodes that never enabled the non-default setting were unaffected by this flaw. The advisory credits Martin Zumsande and Antoine Poinsot with discovering it and reporting it to the security team on Sept. 12, 2025.

You might also like: Bitcoin Core will disclose some bugs sooner. Can node operators update in time?

In the code change, Zumsande explained that incoming Tor connections do not reveal the peer’s actual network address, making address-based matching ineffective. His proposed fix excluded incoming onion connections from whitelist permissions. Developers merged it on Sept. 17, 2025.

Poinsot notified affected software providers two days later, according to the disclosure timeline. Bitcoin Core 30.0 shipped with the fix on Oct. 10, followed by 29.2 on Oct. 14. The advisory lists 28.3 and later minor releases as patched too.

A separate mining bug could halt block template creation

The mining vulnerability, tracked as CVE-2025-62861, received a high-severity rating. It affected versions 28.0 through 28.2 and 29.0 through 29.1.

Bitcoin Core’s advisory describes a problem during chain reorganizations, when transactions from disconnected blocks return to the mempool, the node’s collection of pending transactions.

Rules for version 3 transactions, known as TRUC transactions, normally limit relationships between unconfirmed transactions. During a reorganization, however, transactions returning from valid blocks are supposed to bypass those restrictions.

The bug left a transaction replacement rule active during that process. It could remove a restored transaction while leaving behind transactions that depended on it, producing an inconsistent mempool.

With those missing inputs, the advisory says, a mining node’s proposed block template would fail its validity check. Block template creation could not resume until a restart reloaded the mempool into a consistent state.

Niklas Goegge reported the issue on Sept. 26, 2025. In the fix documentation, developer Greg Sanders explained that skipping the TRUC checks during reorganizations had been the intended behavior, but the relevant bypass argument was not checked. Developers merged the correction on Oct. 2.

Another flaw could repeatedly delay block processing

The third official advisory, CVE-2025-62859, describes a medium-severity vulnerability involving compact blocks, a bandwidth-saving method of relaying blocks between nodes.

A malicious peer announcing a compact block first could cause a victim to request the full block from the same peer and wait through a 10-minute timeout. The delay followed a failed check for altered transaction witness data.

According to the disclosure, an attacker controlling all three of a victim’s high-bandwidth peers could repeat the disruption indefinitely. Nodes running with -blocksonly were another configuration in which repeated stalling was possible. Eugene Siegel reported the flaw on April 28, 2025.

Public details followed the end of support

Bitcoin Core’s disclosure policy normally holds medium- and high-severity vulnerability details until two weeks after the last affected release reaches end of life.

As crypto.news previously reported, an October policy change created a faster disclosure route for easily rediscovered flaws, including issues found through a simple AI prompt.

Earlier fixes addressed different problems. June’s 31.1rc1 release candidate patched a PrivateBroadcast privacy flaw that could expose IP addresses. In May, developers disclosed a script interpreter vulnerability involving a specially crafted block that could remotely crash vulnerable nodes; its fix shipped in Bitcoin Core 29.0 in April 2025.

Read more: SEC’s Selway puts tokenized securities in 24/7 market debate

US crypto regulation hub

Crypto mining in the US: federal rules and the state map

Crypto kiosk rules by state: bans, licenses and the fraud data

Crypto ETF rules in the US: how a fund gets listed now

Crypto banking access in the US: master accounts, the chokepoint, and what changed

CFTC and crypto in 2026: what the agency now governs

Is crypto legal in the US? Yes, and here is the structure

Crypto executive orders: what the White House has actually ordered

SEC crypto enforcement in 2026: from registration war to fraud beat

IRS crypto tax rules in 2026: what actually gets taxed

The OCC and crypto: national trust charters, explained