Bitcoin Core Tor Bug Gave Peers Whitelist Privileges on Thousands of Nodes

Bitcoin Core has disclosed a medium-severity Tor vulnerability, CVE-2025-62860, that handed inbound peers whitelist privileges on thousands of reachable mainnet nodes, granting untrusted connections permissions meant only for trusted peers. The bug affected nodes running a nondefault -whitelist configuration, and fixes shipped across three releases in October 2025.

The flaw sits in how Bitcoin Core identifies inbound Tor connections. The software recognizes them by the Tor daemon's address, which normally belongs to the same machine or local network as the node. If an operator configured a -whitelist IP range that covered that address, every incoming Tor peer inherited whitelist permissions. Those permissions strip away denial-of-service limits and certain privacy-leak mitigations that Bitcoin Core reserves for peers an operator explicitly trusts.

Who was actually exposed?

The vulnerability required a nondefault setup. Only nodes configured with -whitelist were affected at all. Within that group, the exposure concentrated in two categories: node packages that bundled Bitcoin Core together with Tor and configured a whitelist range covering the Tor daemon's address, and third-party client software that required the setting to function. For those operators, unfamiliar connections arriving through Tor could silently receive trusted-peer treatment.

Martin Zumsande and Antoine Poinsot discovered the issue and reported it to the Bitcoin Core security team on Sept. 12, 2025. Patches rolled out on a staggered schedule:

• Version 30.0 shipped the fix on Oct. 10, 2025
• Version 29.2 followed on Oct. 14
• Version 28.3 closed out the series on Oct. 20

The fix is straightforward in operational terms: inbound connections received through an onion address can no longer be granted whitelist permissions, regardless of how the operator's IP ranges are configured.

Why did disclosure take more than a year?

Bitcoin Core disclosed CVE-2025-62860 on Nov. 10, 2026, roughly 13 months after the first patch landed. That timeline follows the project's stated disclosure policy, which schedules public details of medium- and high-severity issues for two weeks after the last affected release series reaches end of life. The final vulnerable series, 29.x, reached end of life on Oct. 27, 2026 — putting the Nov. 10 disclosure right on the policy's clock.

What else came out on Nov. 10?

The same disclosure batch included two additional flaws: a block-processing bug and a mempool flaw that could prevent block-template creation after a chain reorganization. For mining operators and node runners, that combination matters because template-creation failures after reorgs directly affect a pool's ability to build on the freshest chain tip.

The practical takeaway for operators is configuration hygiene. Bundled Tor-plus-Bitcoin-Core packages that auto-applied whitelist ranges were the main vector, and any operator still running a pre-28.3 build with a nondefault -whitelist covering their Tor daemon should treat an upgrade as overdue. With 28.x now the oldest maintained series, nodes on anything older are outside the security-patch window entirely.