Bitcoin Core Tor Whitelist Flaw May Have Affected Thousands of Nodes

Bitcoin Core Disclosed a Tor Whitelist Flaw Affecting Thousands of Configured Nodes

A Bitcoin Core bug could give some incoming Tor connections permissions reserved for trusted peers, but only when operators used a specific, non-default whitelist setting. Bitcoin Core says thousands of reachable mainnet nodes may have used that configuration.

• Using Tor alone did not make a node vulnerable. The flaw required a matching -whitelist configuration.
• The permissions lifted some denial-of-service limits and privacy-leak protections.
• Bitcoin Core lists versions 28.3, 29.2 and 30.0 as fixed.

How an incoming Tor connection matched a whitelist

Bitcoin Core rated the vulnerability, CVE-2025-62860, medium severity. It affected incoming connections through Tor, not simply the use of Tor for outbound connections.

When an incoming Tor connection reached Bitcoin Core through a local Tor proxy, Core saw the proxy’s IP address, not the remote peer’s. The proxy typically ran on the same machine or local network. If its address fell within a range listed in the optional -whitelist setting, Core could apply whitelist permissions to the incoming connection.

Those permissions did not mean a peer was generally safe or trustworthy. Bitcoin Core says whitelisting lifts various denial-of-service limits and privacy-leak mitigations. Applying those exceptions to an incoming peer by mistake could leave a node less protected against disruptive activity and information exposure.

The flaw depended on this configuration. Bitcoin Core says nodes without the non-default -whitelist option were unaffected. Using Tor by itself was not enough.

Bitcoin Core’s estimate: thousands of nodes

Bitcoin Core said popular vendors bundled its software with Tor and set whitelist ranges that matched the Tor proxy. As a result, “thousands” of reachable mainnet nodes treated incoming Tor connections as whitelisted, according to the CVE-2025-62860 disclosure.

The advisory does not name the vendors, give an exact node count or describe how the estimate was made. “Thousands” is Bitcoin Core’s estimate, not an independently verified count. It also does not mean every node using Tor was exposed.

Reported in 2025, publicly disclosed in 2026

Martin Zumsande and Antoine Poinsot reported the flaw to Bitcoin Core’s security team on September 12, 2025. Zumsande opened the proposed fix on September 15, and developers merged it on September 17. Bitcoin Core’s public disclosure is dated November 10, 2026, more than a year after the fix was merged. The disclosure does not explain the delay.

The fix stops incoming Tor connections received on an onion bind from getting whitelist permissions through the affected address match. Bitcoin Core lists versions 28.3, 29.2 and 30.0 as fixed, along with later minor releases in those lines.

Operators should use the latest supported Bitcoin Core release available to them. If you maintain an older release line, check that it is at least one of the listed fixed versions. Review whether -whitelist is enabled, which address ranges it covers and whether those settings are still needed, especially if another application bundles Bitcoin Core with Tor.

Key questions and answers

• Did using Tor make every Bitcoin Core node vulnerable?

  No. The flaw required a matching, non-default -whitelist configuration for incoming Tor connections. Bitcoin Core says nodes without that option were unaffected.

• How many nodes were affected?

  Bitcoin Core reported that thousands of reachable mainnet nodes may have been affected. It did not publish an exact count, name the vendors involved or explain how it measured the number.

• What could the incorrect permissions do?

  They could lift some denial-of-service limits and privacy-leak protections normally applied to peers. The disclosure does not establish that attackers exploited the flaw or quantify any resulting harm.

• Which versions contain the fix?

  Bitcoin Core lists 28.3, 29.2 and 30.0, along with later minor releases in those lines. For security and support, operators should use the latest release available for their setup.