The whitelist was meant to open the door to trusted insiders. Instead, it ended up opening the door to everyone.
On November 10, Bitcoin Core disclosed three vulnerabilities. The one most worth looking at is CVE-2025-62860.
It’s rated medium severity and affects versions before 28.3, 29.2, and 30.0.
For external connections coming in through Tor, the IP address shown is that of the local Tor software.
If that address falls within an IP range configured as trusted with -whitelist, Core treats strangers as trusted insiders on the whitelist.
Once they’re whitelisted, DoS protections are lifted, and measures to mitigate privacy leaks are disabled too.
Why were thousands of mainnet nodes affected?
It wasn’t a problem with Core’s default settings. Nodes that never set a non-default -whitelist were never affected.
The issue was vendors bundling Core with Tor and, while they were at it, configuring -whitelist to match Tor’s address range.
One convenient default opened the door to everyone.
What was lost this time wasn’t coins, but protection.
Spam transactions could flood in without rate limits, and privacy protections failed.
Private keys weren’t stolen, the $BTC supply rules didn’t change, and the amount you hold didn’t change either.
What was weakened was the node’s immune system.
Two more vulnerabilities were disclosed that same day: one high severity and one medium severity.
All three vulnerabilities were fixed in October 2025; they were publicly disclosed on November 10 this year.
The 29.x series reached end of life on October 27, but the announcement wasn’t made until November 10.
People still running 29.x had no security updates available by the time they learned there was a vulnerability.
Disclose too early and you hand attackers an instruction manual; disclose too late and you leave long-time users exposed. That’s the deadlock of disclosure policy.
My take:
The real problem wasn’t in the code, but in the integration—a single vendor default configuration determined the security baseline for thousands of nodes.
The trigger was a “non-default” setting, so ordinary users weren’t directly affected, and the project says it has found no evidence of active exploitation.
What remains unresolved is the gap between “I thought I was safe” and “someone else set up my configuration.”
When you see news like this, ask three questions:
Is it your money or your protections that are affected?
Does it require a non-default configuration—and did I change mine?
When was the fix released, when was the issue disclosed, and how long was the gap between them?
Always review default configurations provided by others yourself.
Who wrote your configuration—the vendor, a tutorial, or you?
Bitcoin Core didn’t disclose this until more than a year later. Do you think that was responsible, or too slow?
#比特币Core披露Tor流量漏洞
On November 10, Bitcoin Core disclosed three vulnerabilities. The one most worth looking at is CVE-2025-62860.
It’s rated medium severity and affects versions before 28.3, 29.2, and 30.0.
For external connections coming in through Tor, the IP address shown is that of the local Tor software.
If that address falls within an IP range configured as trusted with -whitelist, Core treats strangers as trusted insiders on the whitelist.
Once they’re whitelisted, DoS protections are lifted, and measures to mitigate privacy leaks are disabled too.
Why were thousands of mainnet nodes affected?
It wasn’t a problem with Core’s default settings. Nodes that never set a non-default -whitelist were never affected.
The issue was vendors bundling Core with Tor and, while they were at it, configuring -whitelist to match Tor’s address range.
One convenient default opened the door to everyone.
What was lost this time wasn’t coins, but protection.
Spam transactions could flood in without rate limits, and privacy protections failed.
Private keys weren’t stolen, the $BTC supply rules didn’t change, and the amount you hold didn’t change either.
What was weakened was the node’s immune system.
Two more vulnerabilities were disclosed that same day: one high severity and one medium severity.
All three vulnerabilities were fixed in October 2025; they were publicly disclosed on November 10 this year.
The 29.x series reached end of life on October 27, but the announcement wasn’t made until November 10.
People still running 29.x had no security updates available by the time they learned there was a vulnerability.
Disclose too early and you hand attackers an instruction manual; disclose too late and you leave long-time users exposed. That’s the deadlock of disclosure policy.
My take:
The real problem wasn’t in the code, but in the integration—a single vendor default configuration determined the security baseline for thousands of nodes.
The trigger was a “non-default” setting, so ordinary users weren’t directly affected, and the project says it has found no evidence of active exploitation.
What remains unresolved is the gap between “I thought I was safe” and “someone else set up my configuration.”
When you see news like this, ask three questions:
Is it your money or your protections that are affected?
Does it require a non-default configuration—and did I change mine?
When was the fix released, when was the issue disclosed, and how long was the gap between them?
Always review default configurations provided by others yourself.
Who wrote your configuration—the vendor, a tutorial, or you?
Bitcoin Core didn’t disclose this until more than a year later. Do you think that was responsible, or too slow?
#比特币Core披露Tor流量漏洞