block #0043 in --:--:--Join the pool
PENDING…
hype projects ✓ confirmed 6/6 1d ago · 4 min read

bitcoin core tor bug: Tor Strangers Got Trusted-Peer Rights

The bitcoin core tor bug (CVE-2025-62860) let inbound Tor peers inherit whitelist permissions on thousands of nodes; Bitcoin Core disclosed it Nov 10 with two more fixed flaws, all patched in 30.0, 29.2 and 28.3.

bitcoin core tor bug: Tor Strangers Got Trusted-Peer Rights
tl;dr
  • CVE-2025-62860 let inbound Tor peers inherit -whitelist permissions on nodes that whitelisted the Tor daemon's IP range; Core rates it medium severity.
  • A second, high-severity bug could stop a mining node from building valid block templates after a reorg until it was restarted.
  • All three flaws are patched in Bitcoin Core 30.0, 29.2 and 28.3 or later; no attacks were reported in the advisories.
in this block
  1. What actually happened
  2. The other two bugs
  3. What to do as a reader

The bitcoin core tor bug is the headline from a batch of three security advisories Bitcoin Core published on November 10. In plain English: on thousands of reachable nodes, strangers connecting over Tor were treated like trusted local machines. The fix shipped back in October 2025, but the details only went public this week, under Core's disclosure timetable.

What actually happened

Bitcoin Core runs most of the network's nodes. A node normally rate-limits peers and applies privacy protections so random connections cannot spam it or learn too much. The -whitelist option relaxes some of those limits for peers the operator trusts, like another machine on the same home network.

Here is where it broke. When a node accepts Tor connections, the incoming peer appears to come from the local Tor daemon's address. If the operator whitelisted an IP range that included that daemon, every inbound Tor visitor got the trusted treatment too. According to the official advisory, popular vendors bundled Core with Tor and set exactly that kind of whitelist, which led to "thousands of reachable mainnet nodes whitelisting all incoming Tor connections."

Timeline, from the advisory

  • September 12, 2025: Martin Zumsande and Antoine Poinsot report the issue.
  • September 17, 2025: the fix (PR #33395) is merged and backported; Bitcoin Knots' maintainer is informed the same day.
  • September 19, 2025: affected software providers are warned privately.
  • October 2025: fixed releases ship as 30.0, 29.2 and 28.3.
  • October 27, 2026: the last vulnerable series, 29.x, reaches end of life.
  • November 10, 2026: public disclosure.

CoinDesk pointed out the code change was public on GitHub the whole time, under a title that literally said whitelist permissions should not apply to inbound Tor peers. The advisory does not name the vendors that shipped the risky setup. Nodes that never turned on -whitelist were never affected.

The other two bugs

The high-severity one, CVE-2025-62861, lives in mempool policy for version 3 "TRUC" transactions. During a chain reorganization, transactions from abandoned blocks get re-added to the mempool. A "sibling eviction" rule added in v28.0 kept firing during that process, so a node could evict one restored transaction while keeping its children. The mempool then held transactions spending outputs that no longer existed, and block template creation failed its own validity check. For a miner, that means no new blocks until a restart. Affected versions were 28.0 to 28.2 and 29.0 to 29.1. Niklas Goegge reported it.

The third, CVE-2025-62859, is medium severity. A malicious peer could stall a node's block processing for 10 minutes by abusing witness malleation in compact blocks. If an attacker controlled all three of a victim's high-bandwidth peers, or the node ran with -blocksonly, it could repeat that indefinitely. Eugene Siegel reported it.

Decrypt noted that none of the three reached Core's "critical" tier, which is reserved for things like coin theft, inflation or permanent chain splits.

Why the delay

Core publishes medium and high-severity details two weeks after the last affected release goes end of life. The 29.x series hit that point on October 27, so the clock ran out this week. Separately, Core changed its policy in October so that bugs easy to rediscover, including with a simple AI prompt, get patched and disclosed as fast as possible. We covered that shift in bitcoin core ai bugs.

What to do as a reader

If you run a node, the bitcoin core tor bug is a reminder to check your version, not a reason to panic:

  1. Update. Anything at or above 28.3, 29.2 or 30.0 has the fixes. If you are on a plug-and-play node box, confirm your vendor shipped a current Core build.
  2. Audit your config. If you use -whitelist, make sure the range does not cover your Tor daemon unless you truly mean to trust it.
  3. Miners and pools: the reorg bug is fixed in 30.0 and 29.2, so lagging versions are a real operational risk.
  4. Users of Lightning or wallet servers should apply the same habit everywhere; this week's lnbits wallet thefts showed how fast unpatched software gets punished.

None of the three enabled coin theft, per Decrypt's read of the advisories, and no exploitation was reported. The real lesson: patch notes beat Twitter threads. Not financial advice.

Not financial advice. DYOR, ser.

More in the pool

all hype projects
gm ser

Get confirmed before the crowd

Daily block at 07:00 UTC. No spam, just the block, ser.