Bitcoin Core disclosed on Nov. 10 a configuration flaw that caused thousands of reachable Bitcoin mainnet nodes to treat incoming Tor connections as trusted peers, giving those connections exemptions from denial-of-service limits and privacy protections.
The project rated the issue, CVE-2025-62860, as medium severity. Exposure required vulnerable software and a non-default -whitelist setting that covered the IP address of the node's Tor daemon, the software handling its Tor connections. Nodes that never enabled that setting were not affected.
How the trust check failed
For an incoming Tor connection, Bitcoin Core sees the Tor daemon's IP address rather than the remote peer's actual network address. 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. If the range included the daemon, incoming Tor connections inherited the whitelist permissions. The local address identified the intermediary carrying the connection but could not establish which remote peer deserved trust.
The patch excludes incoming onion connections from address-based whitelist grants. Bitcoin Core said the change concerns address-based -whitelist permissions, not every possible peer permission. The -whitelist setting lifts various limits intended to restrict denial-of-service behavior, along with mitigations against privacy leaks.
The project said the issue concerned exemptions granted to network peers and that the privileges described in the disclosure do not establish wallet access or coin theft.
Historical exposure and fixes
Bitcoin Core said popular vendors bundled the node software with Tor and a matching whitelist range, and some client software also required whitelisting and commonly ran alongside Tor. Together, these configurations led thousands of reachable mainnet nodes to whitelist every incoming Tor connection, according to the advisory's historical exposure finding. That is not a count of nodes still vulnerable today.
Martin Zumsande and Antoine Poinsot reported the issue in September 2025. The patch merged on Sept. 17 and stopped applying address-based whitelist permissions to incoming onion connections, whose remote network addresses are concealed.
Bitcoin Core 30.0, 29.2 and 28.3 shipped the fix in October 2025. 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.
What operators should check
Bitcoin Core's maintenance schedule now covers 30.x, 31.x and 32.x; 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. Its download page listed 32.1 as latest as of Nov. 11.
For operators using packaged node software, Bitcoin Core advises checking the Bitcoin Core version actually running and whether its whitelist range includes the Tor daemon's address.
