Bitcoin Core flaw let thousands of nodes trust anonymous Tor peers

Bitcoin Core disclosed on Nov. 10 why thousands of reachable mainnet nodes had treated incoming Tor connections as trusted peers, exempting anonymous remote users from denial-of-service limits and privacy protections. The flaw, rated medium severity as CVE-2025-62860, required vulnerable software plus a non-default whitelist setting covering the node's Tor daemon IP. Nodes without that setting were never affected, and the issue did not involve wallet access or coin theft.

Whitelist setting confused Tor relay with remote peer

For an incoming Tor connection, Bitcoin Core sees the IP address of the local Tor daemon rather than the remote peer's actual network address, as the daemon usually runs on the same machine or local network. On affected configurations, Core checked that address against an IP range marked as trusted with the -whitelist option. If the range included the daemon, every incoming Tor connection inherited those permissions. The local address identified only the intermediary carrying the connection and could not establish which remote peer deserved trust.

The disclosure says popular vendors bundled node software with Tor and a matching whitelist range, while some client software also required whitelisting and commonly ran alongside Tor. Together, those setups led thousands of reachable mainnet nodes to whitelist every incoming Tor connection. The -whitelist option lifts various limits intended to restrict denial-of-service behavior, along with mitigations against privacy leaks. That count describes historical exposure, not nodes still vulnerable today. The issue was reported in September 2025 by Martin Zumsande and Antoine Poinsot, with a patch merged on Sept. 17 that stopped applying address-based whitelist permissions to incoming onion connections.

What node operators need to verify now

Fixed versions Bitcoin Core 30.0, 29.2 and 28.3 shipped in October 2025, and the fix is present in all versions from 30.0 onward as well as later minor releases in the fixed 28.x and 29.x branches. Maintenance now covers the 30.x, 31.x and 32.x lines, while 28.x and 29.x have reached end of life. The project recommends the latest maintenance release of the newest major version an operator can adopt, with 32.1 listed as latest as of Nov. 11. Operators using packaged software should check the Core version actually running and whether its whitelist range includes the Tor daemon address.

The finding does not show ongoing compromise or loss of funds, and it does not apply to nodes that never enabled the relevant whitelist range. What remains unknown from the disclosure is how many operators have updated or corrected configurations since October 2025. The guidance matters only for people running Bitcoin nodes, particularly bundled packages with Tor, and not for ordinary holders who do not operate network infrastructure.