Thousands of Bitcoin nodes gave anonymous strangers a pass around security limits

Bitcoin Core disclosed a configuration flaw on Nov. 10 that caused thousands of reachable Bitcoin mainnet nodes to treat incoming Tor connections as trusted peers, giving them exemptions from denial-of-service limits and privacy protections.

The project rated CVE-2025-62860 medium severity. It affected vulnerable releases when a non-default -whitelist setting covered the IP address of the node's Tor daemon, the software handling its Tor connections. Nodes that never enabled that setting were never affected.

The fixes shipped in October 2025. The new disclosure explains how a configuration intended for trusted connections spread through bundled software and granted those privileges to remote Tor peers.

For an incoming Tor connection, Bitcoin Core sees the Tor daemon's IP address rather than the remote peer's actual network address. That 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.

How Tor peers inherited local trust

On vulnerable configurations, an IP whitelist trusted the local Tor daemon's address and passed exemptions to incoming remote peers.
REMOTE TOR PEERSABCTor daemonUsually on the samemachine or local networkVisible IP:the daemon'sBitcoin Corereceives the connectionRemote peers' actual network addresses remain concealed.Peer markers are illustrative, not a node count.
REMOTE TOR PEERSABCTor daemonUsually on the same machineor local networkCore sees thedaemon's IPBitcoin CoreActual remote IPs concealedPeer markers are illustrative,not a node count.

What changes at the trust check

What changes at the trust checkBefore fix + matching whitelistWith the fix
A vulnerable release used the daemon's matching IP range to grant trusted-peer exemptions.
VULNERABLE CONFIGURATIONDaemon IP matches whitelistNon-default trusted IP rangeApply trustTrusted-peer exemptionsVarious DoS / privacy safeguards lifted
VULNERABLE CONFIGURATIONDaemon IP matches whitelistNon-default trusted IP rangeApply trustTrusted-peer exemptionsVarious DoS / privacy safeguards lifted
Incoming onion connections bypass address-based whitelist matching, preventing this mistaken grant.
FIXED COREIncoming onion connectionAddress matching is skippedSkip IP trustNo privileges from this ruleDaemon IP cannot grant trust
FIXED COREIncoming onion connectionAddress matching is skippedSkip IP trustNo privileges from this ruleDaemon IP cannot grant trust

The patch excludes incoming onion connections from address-based whitelist grants.

Before-fix state requires a vulnerable release and a non-default whitelist matching the Tor daemon. The change concerns address-based -whitelist permissions, not every possible peer permission.
Sources and evidence

Sources

1. Bitcoin Core disclosure
2. Bitcoin Core patch #33395

Supporting facts

• On vulnerable Bitcoin Core releases, the flaw affected nodes whose non-default -whitelist IP range matched their Tor daemon's address. [1]
• For incoming Tor connections, Bitcoin Core sees the Tor daemon's IP address, usually on the same machine or local network, rather than the remote peer's actual network address. [1] [2]
• The -whitelist setting exempts trusted peers from various denial-of-service limits and privacy-leak mitigations; matching the Tor daemon's address mistakenly extended those privileges to incoming Tor peers. [1]
• The patch stops address-based whitelist permissions from being applied to inbound onion connections because their remote network addresses are not revealed. [2] [1]

Method

Qualitative connection path plus two reported states. Peer markers illustrate multiple remote connections and encode no count or scale.

Scope

Before-fix state requires a vulnerable release and a non-default whitelist matching the Tor daemon. The change concerns address-based -whitelist permissions, not every possible peer permission.
Infographic by CryptoSlate

That distinction matters because -whitelist lifts various limits intended to restrict denial-of-service behavior, along with mitigations against privacy leaks. The issue concerned exemptions granted to network peers; the privileges described in the disclosure do not establish wallet access or coin theft.

Bitcoin Core says popular vendors bundled the node software with Tor and a matching whitelist range. 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.

That is the advisory's historical exposure finding, 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 node operators should check now

Those older patch thresholds are separate from today's upgrade guidance. 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 lists 32.1 as latest as of Nov. 11.

For operators using packaged node software, check the Bitcoin Core version actually running and whether its whitelist range includes the Tor daemon's address.

This content is provided for general informational purposes only and doesn't constitute financial, investment, legal, or tax advice. Any events, rewards, online promotions, or related information mentioned herein should not be considered a recommendation, solicitation, or invitation to purchase, sell, trade, or otherwise deal in any crypto assets. Crypto assets are highly volatile and may result in loss. The availability of WEEX services, products, and related events may vary by region. You are responsible for ensuring that your participation is in accordance with applicable local laws and regulations.