In This Article
A vulnerability was discovered in Bitcoin Core that granted incoming Tor connections trusted access rights to thousands of nodes, thereby removing part of the protection against spam and confidential information leaks.
In a Bitcoin Core security notice published on November 10, the vulnerability in Tor was designated CVE-2025-62860. Developers disclosed the details along with information about two other vulnerabilities after support for the last affected release series, 29.x, ended on October 27.
Bitcoin Core Whitelist Settings Allow Tor Traffic to Bypass Restrictions
According to the notice, incoming Tor connections were displayed to Bitcoin Core under the IP address of the Tor software, which typically ran on the same computer or the same local network. When this address matched a range specified using the optional -whitelist setting, external connections received permissions intended for trusted connections.
Using the whitelist removes various restrictions that prevent denial-of-service attacks and provides protection against confidential information leaks. According to the developers, popular providers bundled Bitcoin Core with Tor and configured the corresponding whitelist ranges, resulting in thousands of accessible mainnet nodes accepting all incoming Tor connections with the corresponding privileges.
Nodes that never enabled the non-default setting were not affected by this vulnerability. The notice states that Martin Zumsande and Antoine Poinsot discovered it and reported it to the security group on September 12, 2025.
In his code change, Zumsande explained that incoming Tor connections do not reveal the peer’s actual network address, making address-based matching ineffective. The fix he proposed excluded incoming Onion connections from whitelist permissions. Developers merged it on September 17, 2025.
According to the timeline of events, Poinsot notified the affected software providers two days later. Bitcoin Core 30.0 was released with the fix on October 10, followed by version 29.2 on October 14. The notice also states that fixes were incorporated into versions 28.3 and subsequent minor releases.
Separate Mining Bug Could Halt Block Template Creation
The mining vulnerability, registered under the number CVE-2025-62861, received a high severity rating. It affected versions 28.0–28.2 and 29.0–29.1.
The Bitcoin Core advisories describe a problem that occurs during a chain reorganization, when transactions from disconnected blocks are returned to the mempool — the set of a node’s pending transactions.
The rules for version 3 transactions, known as TRUC transactions, normally restrict relationships between unconfirmed transactions. However, during a reorganization, transactions returning from valid blocks are supposed to bypass these restrictions.
Due to the bug, the transaction replacement rule remained active during this process. It could remove a restored transaction while leaving behind transactions that depend on it, leading to an inconsistent memory pool.
The notice states that with these inputs missing, the block template proposed by the mining node would fail the validity check. Block template creation could not resume until a restart reloads the memory pool into a consistent state.
Niklas Gögge reported this issue on September 26, 2025. In the fix documentation, developer Greg Sanders explained that skipping TRUC checks during reorganizations was intended behavior, but the corresponding bypass argument was not being verified. Developers merged the fix on October 2.
Another Flaw Could Cause Repeated Block Processing Delays
A third official notice, CVE-2025-62859, describes a medium-severity vulnerability affecting compact blocks — a method of relaying blocks between nodes that saves network bandwidth.
An attacker who was the first to announce a compact block could force the victim to request the full block from the same network participant and wait for a 10-minute timeout. The delay occurred due to a failed check for modified transaction witness data.
According to the information received, an attacker controlling all three of the victim’s high-speed nodes could repeat the failure indefinitely. Nodes running with the -blocksonly parameter represented another configuration in which repeated delays were possible. Eugene Siegel reported this vulnerability on April 28, 2025.
