The darknet, also known as the dark web, is a concealed section of the internet that's inaccessible via standard search engines. You can only access it using special software, settings, or authorization. This area comprises websites and content that are purposely kept hidden from public view.
Accessing darknet requires using Tor Browser, a special web browser that routes your internet traffic through a global network of relays managed by volunteers. This way, it becomes very difficult to trace which websites you're visiting, and these sites won't know where you are located.
When visiting the dark web, use a secure browser like Tor, do not reveal any of your personal information, and don't open suspicious files or links to stay safe.
The Darknet is often utilized for secure communication, discreet information or file sharing, anonymous research without identity exposure, and occasionally for engaging in illicit activities. It is also recognized for hosting underground black markets(darknet markets), whistleblowing platforms, and discussion boards that champion freedom of speech.
While accessing Darknet Markets themselves is typically not against the law in most places, engaging with illicit goods within them is generally considered a crime. On the other hand, some people might visit Darknet Markets for lawful purposes such as research, journalistic work, or simply to explore online communities. It's essential to know the local laws regarding online activities, and be cautious when using these platforms to avoid any potential issues.
Onion addresses can change because of key rotation, DDoS mitigation, takedowns, migrations, or compromise. Old links and bookmarks can go stale, so verify the current address through a trusted source and record the date you checked it.
Monero (XMR) is a privacy-focused cryptocurrency. Many darknet markets accept or prefer it because transactions are designed to obscure sender, receiver, and amount, though no system is perfectly anonymous in every context.

Service categories

Article categories

Latest articles

News

A Bitcoin Core Whitelist Bug Quietly Trusted Every Incoming Tor Peer

Bitcoin Core published three security advisories on Tuesday, roughly a year after the fixes shipped. The one that matters most if you run a node behind Tor is CVE-2025-62860, and the reason it matters is not that it was clever. It is that a lot of people had the affected setup without realising it.

The short version: on Bitcoin Core before 28.3, 29.2 and 30.0, an inbound Tor connection could inherit the permissions of a trusted peer. Bitcoin Core sees the Tor daemon's IP address, not the remote peer's real address, and that daemon usually runs on the same machine or local network. If your -whitelist range covered the daemon address, the node treated incoming onion connections as whitelisted. Whitelisting lifts various denial-of-service limits along with the mitigations that normally keep peers from learning too much about you.

Why thousands of nodes had it

Whitelisting is not a fringe setting. Bitcoin Core's own advisory says popular vendors bundled the node software with a Tor daemon and set -whitelist to an IP range matching that daemon. Some client software also required whitelisting and was commonly run alongside Tor. Put those together and the configuration becomes a standing invitation: whitelist every incoming Tor connection. The advisory says this reached thousands of reachable mainnet nodes. That is a historical exposure figure rather than a count of nodes still vulnerable today, but it is a large number for a config mistake.

It is rated medium severity, and it is worth being precise about what it is not. The exemptions did not grant wallet access and could not move coins. What they removed were anti-DoS protections and privacy-leak mitigations for strangers arriving over Tor — peers whose real addresses you were never going to see anyway.

The fix, and why it is only being discussed now

Martin Zumsande and Antoine Poinsot reported the flaw on 12 September 2025. Zumsande opened PR #33395 three days later, it merged and was backported on 17 September, and the same day Poinsot flagged it to Bitcoin Knots maintainer Luke Dashjr, who acknowledged it. On 19 September he notified several affected software providers. Fixes landed in Bitcoin Core 30.0 on 10 October 2025, then 29.2 on 14 October and 28.3 on 20 October. The last vulnerable branch, 29.x, went end of life on 27 October 2026, and the details went public on 10 November. Nodes that never set the non-default -whitelist option were never exposed.

The other two advisories

CVE-2025-62861 is the one to notice if you mine. It is rated high severity. The TRUC "sibling eviction" logic, introduced in v28.0, was not gated on the bypass_limits flag that a reorg uses when re-adding disconnected transactions to the mempool. A reorg could restore a transaction topology that is valid inside a block but impossible under mempool policy, evict a restored transaction while leaving its in-mempool descendants behind, and leave the mempool referencing outputs that no longer existed. The practical result is that block template creation fails, and keeps failing until the node is restarted. Niklas Goegge reported it on 26 September 2025. It affected versions 28.0 to 28.2 and 29.0 to 29.1, and was fixed in 30.0, 29.2 and 28.3.

CVE-2025-62859 is a medium-severity stall. On versions before 29.2 and 30.0, a node cleared the download state for a compact block before checking for witness malleation. If that check failed, the node fell back to requesting the block from the same peer via GETDATA with a ten-minute timeout. A peer that announced the compact block first could use this to stall block processing, and could repeat it indefinitely if it controlled your three high-bandwidth peers or if you ran with -blocksonly. Eugene Siegel reported it, and it was fixed in 30.0 and 29.2.

What to do

Check the version you are actually running, not the one your package manager says you installed. Bitcoin Core's download page listed 32.1 as the latest release on Tuesday. Anything from 30.0 onward carries all three fixes, as do 28.3 and 29.2, but 28.x and 29.x are end of life and the project recommends the newest major version you can adopt.

If you run a packaged node that ships Tor and a whitelist, look at what that whitelist range covers. If it includes the Tor daemon's address, that is the configuration behind this advisory, even on a fixed version. After the patch it is no longer a vulnerability, but it is still worth knowing why it is set and whether you need it.

The wider point is one that keeps coming up with node software. The bugs are usually small. The blast radius comes from how the software is bundled, what defaults it ships with, and how long the people running it take to update. About a year passed between the fixes and this disclosure, which is roughly how Bitcoin Core's embargo policy is designed to work: details wait until the last vulnerable release is out of support. The upside is that there was time to patch. The downside is that whoever reads the November advisory has been running either a fixed node or a vulnerable one for a year.

Sources