In September 2025, Martin Zumsande stumbled upon a bunch of misbehaving Bitcoin Knots nodes. This led us to discover a widespread configuration bug which exposed Bitcoin Knots and Bitcoin Core nodes to privacy leaks and various DoS vectors.

It already feels far away, but until not too long ago Bitcoin was targeted by a campaign of disinformation and harassment to promote a misguided fork coin. This all started when a group of Bitcoin enthusiasts, vocal on social media, objected to a default relay policy change in Bitcoin Core. They decided to turn to Bitcoin Knots as an alternative, at the time still merely a fork of Bitcoin Core’s software, not yet of the Bitcoin network.

Some seized on the discontent to politicize Bitcoin’s reference implementation development process, using the all-too-effective tactic of Accusation in a Mirror, amplified by social media. Others fueled the controversy through virtue signaling or attention seeking, seemingly unaware of the harm they were causing.

For context, September 2025 was around the release of Bitcoin Core 30, just before the publication of the consensus change later enforced by Knots. On the mass psychosis timeline, we’re right in the middle of the “Bitcoin Core v30 will insta-kill Bitcoin with CSAM” narrative. We are past accusations of Bitcoin contributors being pedophiles and the release of deepfake sexual videos targeting one of them, just not quite yet at the justification of a “temporary” emergency confiscation fork or one of Bitcoin’s most productive contributors in recent years quitting over personal attacks.

During this period, the meaningless “node count” metric was a central talking point of Knots promoters. While this count was artificially inflated for social media campaign purposes, a non-trivial chunk of them were simply that of people discontent with Bitcoin Core’s relay policy. Intrigued, my (then) colleague Martin figured a lower bound could be established pretty easily.

Bitcoin nodes gossip about other nodes they know of to help peers discover each other. A peer can request a sample of these addresses using a GETADDR message. To limit how much information about the network topology can be gathered this way, Bitcoin Core caches its responses to GETADDR for 24 hours, returning the same set of addresses to repeated requests instead of revealing new ones each time.

This also provides a convenient way to detect Sybils: if multiple advertised nodes return the exact same cached response, they are likely instances of the same underlying node. Counting these duplicates can therefore establish a lower bound on the number of fake nodes. In running this experiment, Martin unexpectedly discovered that the vast majority of Knots nodes on Tor did not cache their GETADDR responses at all!

Martin mentioned this discovery to me, and I started investigating the diff between the Knots release and its Bitcoin Core counterpart. Surely, I thought, the bug must be somewhere among the many unreviewed changes Knots had made to Bitcoin Core. Turns out there was indeed a bug hiding in there, but this was only part of the story…

After a couple hours of investigations, myself and another colleague failed to find what could cause this misbehaviour, and failed to reproduce it. Eventually, we decided the side quest was not worth it and went back to work. Before calling it a day though, Martin let a more comprehensive experiment run overnight, which revealed something interesting… Only the Knots plus Tor combination was affected: the vast majority of Knots nodes on clearnet, and Core nodes on either network, did cache the response to a GETADDR.

When checking the result of the experiment the next day, we struggled to make sense of it. Not only was the bug specific to Knots, it was also specific to Tor, and we couldn’t reproduce it locally.

Martin also mentioned that the distribution of Knots nodes is heavily skewed towards Tor, contrary to that of Core nodes. This is what prompted his Sybil investigation in the first place, as Tor identities are free to create. However I pointed that this distribution could simply be explained by the commercial success of some Knots turnkey solution. That’s because turnkey node-in-a-box solutions commonly (ab)use Tor as a VPN for remote access behind a NAT.

From past experience, I also knew such solutions set the whitelist configuration, because some of the apps they bundle need it (for bloom filters, or privileged p2p access). Could it be?.. BINGO! Start9 whitelisted all of localhost, which included the Tor daemon. Bitcoin Core and Bitcoin Knots would apply the whitelist by treating inbound Tor connections as coming from the IP of the Tor daemon. Bitcoin Knots lifted more protections by default for whitelisted peers, including the ADDR caching privacy leak mitigation, which is what made this issue observable there.

While it was made worse by, and only visible on, Knots, it is important to highlight this issue affected all users of Bitcoin Core and Bitcoin Knots that configured -whitelist with an IP range that included the Tor daemon used by their node. This is a non-default configuration that was surprisingly widespread. All turnkey node solutions I knew of were affected, and high profile projects like Electrs or BTCPayServer recommended setting -whitelist in their documentation.

Therefore the misbehaviour observed on hundreds of Bitcoin Knots nodes was actually a symptom of something far more widespread, and concerning. With -whitelist set to the IP range of the Tor daemon, your node would lift various DoS and privacy protections for all incoming Tor peers. This meant that affected nodes could be trivially DoSed and footprinted.

We chose not to probe nodes to get the total number of affected nodes. That can be extrapolated from the Knots numbers though, where 80% of ~3.5k nodes were demonstrably affected. About twice as many Core nodes were running behind Tor, and even if we conservatively estimate a third of which to be turnkey setups, the total is already about 5,000 affected nodes.

We alerted the Bitcoin Core security team on September 12. Because the vast majority of Knots nodes were affected, we also notified Luke Dashjr. This was a gamble, given his ongoing personal attacks against Bitcoin Core contributors and the conspiracy theories he was spreading about the project. His affiliates had also made legal threats against mining pools running Bitcoin Core. We were worried he might end up exploiting the vulnerability to spread more FUD about Bitcoin Core, justifying such an attack through the same narrative he had built around the project to rationalize his behaviour and, eventually, his fork coin.

I messaged Luke on September 17. He acknowledged receipt the same day and signaled he would respect the embargo period. To his credit, he has as far as I know not broken the embargo nor tried to exploit this vulnerability to his benefit. He even offered to credit me publicly on responsibly disclosing a security issue to Knots, when the discourse shifted to “Bitcoin Core uses its security policy to push CSAM on its users” (it’s embarrassing to write such a ridiculous statement, but it’s important to remember how low parts of our community had fallen during that time). I declined, as I figured it unnecessarily risked revealing the vulnerability before many users had the opportunity to patch their node.

Bitcoin Core fixed the surprising behaviour of applying the whitelist to inbound Tor peers in PR #33395, which shipped in 28.3, 29.2 and 30.0 a month later. But projects did not need to wait for a Bitcoin Core release to distribute a patch to their users. In fact, indiscriminately whitelisting an entire IP range by default is pretty risky to start with. For a security critical project, it’s preferable to block everything by default, and only make pinpointed exceptions.

But this is much less flexible, and turnkey nodes may not know what IP address future whitelist-requiring applications will use. Bitcoin Core offers an option that can prevent the footgun without losing too much flexibility: -whitebind. By using this option you make your bitcoind listen on additional ports (presumably on a loopback address). This can be used to give more fine grained permissions (for instance none on port 8333, “noban” on port 9333, “bloomfilter” on port 10333, etc..) and make it harder to misuse: presumably a proxy for untrusted peers would be configured to connect to the default port, and wouldn’t silently give peers additional permissions simply by virtue of running a local daemon. This was the approach used by nix-bitcoin, a node-in-a-box solution that was not affected by the vulnerability.

I reported this issue to various affected projects that were shipping software directly to end users. I contacted Nix-Bitcoin, Start9, Umbrel, Raspiblitz, Nodl and MyNode. Nix-Bitcoin had already discovered and patched the issue in 2021 (see above). Start9, Umbrel, Raspiblitz and Nodl were responsive. All of them promptly implemented a mitigation and shipped it to users. MyNode was a bit harder to reach, but they eventually shipped a fix (approximately a month later). I also shared the issue with Nicolas Dorier, since BTCPayServer requires a whitelisted connection for its indexer to work properly. He checked and told me their Docker configuration, which is the recommended way of deploying BTCPayServer, was not affected.

The details of the vulnerability have just been published by the Bitcoin Core project in a security advisory, following its security disclosure policy.

As of November 2026, most nodes have upgraded to a Bitcoin Core version that contains the mitigation. 13% of reachable peers are still running a version without the mitigation behind Tor, which could be vulnerable if configured with a whitelisted IP range that includes the Tor daemon. Out of those, 80% run version 28 or earlier, which have been EOL for 6 months or more and are already affected by publicly disclosed vulnerabilities, some of them high-severity.

To conclude, this is not the most exciting security vulnerability I’ve been involved in reporting (or patching), but it’s certainly one where the embargo period felt the most awkward. There was something surreal about coordinating a responsible disclosure with Luke, who was perfectly reasonable in our private exchanges while continuing his attacks on Bitcoin Core contributors in public. And there was a certain irony in watching those who had turned their preference for Knots into a campaign against Bitcoin Core and its contributors post about upgrading to the latest Knots release to “own” Core developers, unaware that the update protected them from a vulnerability responsibly disclosed to Knots, and fixed, by those very developers.