Bitcoin Core Tor whitelist bug: thousands of nodes treated strangers as trusted peers

Bitcoin Core disclosed three more security vulnerabilities on November 10, 2026. The most consequential one affects nodes that run Bitcoin Core together with the anonymity network Tor: anyone who had set the -whitelist option for an IP range also treated every inbound Tor connection as a trusted peer, up to versions 28.3, 29.2 and 30.0. According to the developers, this affected thousands of reachable nodes on mainnet. All three bugs were fixed more than a year ago, so if you keep your node up to date, you are protected. If you still run a version older than 30.0, you should update now, because 29.x, the last affected release series, reached end of maintenance on October 27.

Bitcoin Core is the reference software of the Bitcoin network. A node is a computer that runs this software, verifies every block itself and relays transactions to other nodes. If you run your own node, you do not rely on third-party servers to know your balance. We have worked out how much effort and electricity that takes in our guide on how to run a Bitcoin node.

Bitcoin Core vulnerabilities: three disclosures on November 10

The three advisories carry the identifiers CVE-2025-62859, CVE-2025-62860 and CVE-2025-62861. A CVE number (Common Vulnerabilities and Exposures) is a globally unique identifier for a publicly known security flaw. Bitcoin Core rates two of the three bugs as medium severity and one as high. The timing follows the project's disclosure policy: a vulnerability is only described publicly once the last affected release series no longer receives maintenance.

That threshold was reached on October 27, 2026. On that day maintenance for Bitcoin Core 29.x ended, after version 32.1 had been released on October 27. The maintenance releases 31.2, 30.4 and 29.5 followed on October 28, and on the same day the project had already disclosed three other bugs, which we covered in our article on three security flaws in Bitcoin Core. The new advisories are the second round within two weeks, but they concern different parts of the software.

What the three cases have in common is that outside developers found the bugs and reported them confidentially to the project's security list. The fixes went quietly into versions 28.3, 29.2 and 30.0, released between October 10 and October 20, 2025. They are only being described publicly now, a little over a year later.

Tor whitelist bug: why Tor connections were treated as trusted

The bug tracked as CVE-2025-62860 sits in a setting that many home users never configured themselves. With -whitelist, an operator marks certain peers as trusted. For those peers, according to the project's security advisory, Bitcoin Core lifts various limits against denial-of-service attacks and relaxes protections meant to stop information about the node from leaking out. The feature is intended for your own devices on the home network, such as a second computer or wallet software that talks directly to the node.

The problem arises from the way Tor delivers connections. A stranger's computer that reaches a node via Tor does not appear to Bitcoin Core with its own address. All the node sees is the address of the Tor service, which usually runs on the same device or on the same home network. If that address fell within the IP range the operator had allowed via -whitelist, every inbound Tor connection ended up on the list of trusted peers. Any participant on the internet thus obtained the same rights as your own device in the living room.

This is fixed in Bitcoin Core 30.0 and all later versions, as well as from maintenance releases 28.3 and 29.2 onwards. Since then, inbound Tor connections arriving via an address set up specifically for Tor (onion bind) never receive whitelist permissions. Nodes that had never set the -whitelist option were not affected at any point, according to the developers.

The vulnerability was found by Bitcoin Core developers Martin Zumsande and Antoine Poinsot, who reported it to the security team on September 12, 2025. The fix was merged on September 17, 2025 and backported to older release series. On the same day, according to the advisory, Poinsot also informed Luke Dashjr, who maintains the alternative node software Bitcoin Knots, and on September 19 several affected software vendors.

Bitcoin node packages: where the thousands of affected nodes came from

The reason the flaw had such a broad reach lies in an industry habit. According to the security advisory, popular vendors shipped Bitcoin Core together with a Tor service and set the -whitelist option by default to an IP range that also contained the Tor service. On top of that, add-on software built on Bitcoin Core required the whitelist setting in order to work. These programs often run alongside a Tor service. The developers describe the result as follows: thousands of reachable nodes on mainnet whitelisted every inbound Tor connection.

Many home users will recognise the picture. Ready-made node packages for small computers bundle Bitcoin Core, Tor, a server for wallet queries and often Lightning software under a graphical interface. Users rarely get to see the configuration file. The advisory does not say whether any particular package was affected; the vendors were informed a little over a year ago. If you use such a package, you will usually find the bundled Bitcoin Core version in the app overview or in the package's release notes.

The distinction between the package and the Bitcoin Core version it contains matters. A package can be freshly updated and still ship an older Bitcoin Core version if that individual app has not been brought up to date. For the three vulnerabilities, only the Bitcoin Core version number counts.

CVE-2025-62859: compact blocks and the ten-minute wait

The second medium-severity flaw concerns the way nodes exchange new blocks efficiently. Compact blocks are a method in which a node does not transmit the full block, only short identifiers of the transactions it contains. The recipient reassembles the block from transactions it already holds in its memory pool. This saves bandwidth and speeds up the propagation of new blocks across the network.

Before versions 29.2 and 30.0, Bitcoin Core cleared its download state after reconstructing such a block, before checking for a specific manipulation of the signature data (witness malleation). If that check failed, the node requested the block again from the same peer, with a ten-minute timeout. An attacker who was first to announce a new block to a node could thereby stall its block processing.

The advisory names two conditions under which the attack could be repeated indefinitely: if the attacker controlled all three peers the node uses for high-bandwidth block relay, or if the node ran in -blocksonly mode, relaying only blocks and no loose transactions. The bug was discovered by developer Eugene Siegel and reported on April 28, 2025. The fix by Gregory Sanders was merged on June 30, 2025.

For a home node, such a stall mainly means that it falls behind on new blocks. The wallet connected to it then shows incoming payments later. If you receive bitcoin and confirm receipt through your own node, in the worst case you see an outdated state.

CVE-2025-62861: TRUC transactions halt miners after a reorg

The only flaw rated high severity mainly affects miners. TRUC stands for Topologically Restricted Until Confirmation and refers to version 3 transactions under BIP 431. Stricter rules apply to them until they are confirmed: at most one unconfirmed parent and at most one unconfirmed child. These rules apply only to a node's memory pool (mempool), not to the consensus rules. A valid block may therefore be structured quite differently.

Since version 28.0, Bitcoin Core has had a replacement rule for these transactions known as sibling eviction. If a TRUC transaction gets a second unconfirmed child, the new child evicts the old one provided it pays enough in fees. During a reorganisation, when a node switches to a longer competing chain of blocks, Bitcoin Core puts the transactions from the discarded blocks back into the mempool. In that process the eviction rule wrongly kept running.

The consequence, according to the advisory: transactions remained in the mempool that spent outputs no longer present there. A miner whose node went through such a reorganisation could no longer create a valid block template until it restarted the node. Versions 28.0 to 28.2 and 29.0 to 29.1 are affected; the bug is fixed in Bitcoin Core 30.0 of October 10, 2025. It was reported by Niklas Gögge on September 26, 2025.

Bitcoin Core severity ratings: high and medium for the three flaws

Bitcoin Core assigns every reported vulnerability to one of four classes, which the project describes on its security advisories page. Critical bugs are those that threaten the security of the entire network, such as theft of coins at protocol level, creation of coins outside the fixed issuance schedule or a permanent split of the network. None of the three new flaws falls into this class.

High severity covers bugs with a significant impact on affected nodes or the network that can typically be exploited remotely and under default settings. Medium severity covers bugs that noticeably degrade performance or functionality but whose reach or exploitability is limited. For the Tor flaw, this means the bug only took effect with a whitelist set, but there it hit a very large number of nodes at once.

The classification helps answer how urgent an update is. A home node that does not produce blocks is practically untouched by the high-severity TRUC flaw, because it affects the creation of block templates. For home users, the two medium-severity flaws are the more important ones, because they concern the privacy and availability of your own node.

Bitcoin Core 29.x end of life: no security updates since October 27

Under its own lifecycle policy, the project always maintains the three most recent major versions. Since version 32.0 these are 32.x, 31.x and 30.x. Major versions that drop out of this window generally no longer receive security fixes. The current releases are 32.1 of October 27 and 31.2 and 30.4 of October 28, 2026.

If you still run a 29 version, you do have a patched release for the three new flaws in 29.5, but you will receive no further fixes. Moving to a maintained major version is therefore the cleaner route. Before a large version jump it is worth reading the release notes, because default settings can change.

You can see your own version with the command bitcoin-cli --version or in the output of bitcoin-cli getnetworkinfo under the subversion field, which reads something like /Satoshi:30.4.0/. In the Bitcoin-Qt graphical interface you will find it under Help and About. With all-in-one packages it is usually shown in the overview of installed apps.

Whitelist setting in bitcoin.conf: which lines stand out

Regardless of the version, it is worth looking at the configuration file bitcoin.conf. Lines beginning with whitelist= give peers special permissions. If an entire IP range is listed there, such as your home router's network or an internal container network, you should know which devices sit in it and whether a Tor service is among them. If you did not create the file yourself, with all-in-one packages you can often only reach it through advanced access to the machine.

From Bitcoin Core 30.0, 29.2 and 28.3 onwards, the software no longer treats inbound Tor connections arriving via the address set up for that purpose as trusted in any case. With a current version, the core of the flaw is closed even if the whitelist line stays unchanged. A narrowly defined whitelist is still good practice, because every exception removes protective limits.

Bitcoin wallet and holdings: why the flaws cost no coins

The good news for investors: according to the project's classification, none of the three flaws made it possible to steal coins or create new ones. For most home users the private keys sit in a separate wallet anyway, not in the node itself. If you keep your holdings on a hardware wallet and use the node only as your own verification layer, you keep keys and network software cleanly apart. Our hardware wallet comparison shows which devices are suitable.

The risks lay in availability and privacy. A peer with whitelist permissions faces fewer limits against overload and receives information the node would otherwise withhold from strangers. For users who rely on Tor precisely for anonymity, this is the most sensitive point. A node that falls behind on new blocks also shows incoming payments late.

If you do not run your own node, the three flaws do not affect you directly. Mobile software wallets usually query third-party servers operated by the provider, and exchanges hold their customers' coins on their own infrastructure. Our software wallet comparison gives an overview of wallets that work without your own node.

Bitcoin Core flaws: all three closed from version 30

The three disclosures of November 10 describe bugs that have been fixed since October 2025. The people at risk are those who run a node on an older version and have put off the update for a year. Three steps are enough:

1. Check the version and update: if your node is below 30.0, switch to a maintained major version such as 30.4, 31.2 or 32.1. If you hold your coins only on an exchange, you do not need your own node; you can find reputable providers in our crypto exchange comparison.
2. Trim the whitelist: go through every line starting with whitelist= in bitcoin.conf and restrict it to the devices you actually know. For wallet queries without your own node, our software wallet comparison can help.
3. Separate keys from the node: keep larger holdings on a hardware wallet and use the node only for verification. The hardware wallet comparison lists suitable devices.

(As of November 11, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)