Bitcoin Core published details on Tuesday of three vulnerabilities it fixed more than a year ago, including a high-severity bug that could leave a mining node unable to build new blocks after a chain reorganization until it was restarted. The fixes shipped in October 2025, but a snapshot of the public network on Wednesday still showed roughly 1,900 reachable nodes reporting one of the affected releases.
The mining bug
The high-severity flaw, CVE-2025-62861, sits in how Bitcoin Core handles TRUC, or version 3, transactions. Under BIP 431, a TRUC transaction may have at most one unconfirmed ancestor and one unconfirmed descendant in the mempool. Those are relay policy rules, not consensus rules, so a valid block can still contain a TRUC parent with several children.
Release 28.0 added “sibling eviction”, which lets a new child that pays enough replace an existing one. The problem appeared during reorgs. When blocks are disconnected, their transactions go back into the mempool with policy limits switched off, but the sibling-eviction check still ran. A reorg could therefore restore a set of transactions, evict one of them and leave its descendants behind, so the mempool held transactions spending outputs that no longer existed.
According to the advisory, the result was that a miner’s block template “can no longer succeed”: the template failed its own validity check, and the node could not produce blocks until a restart reloaded a consistent mempool. Versions 28.0 to 28.2 and 29.0 to 29.1 were affected. Niklas Gögge reported the bug on Sept. 26, 2025, Greg Sanders opened the fix in pull request 33504 three days later, and it shipped in Bitcoin Core 30.0 on Oct. 10, 2025, followed by 29.2 and 28.3. The advisory does not report any exploitation.
Two medium-severity flaws
The first medium-rated bug, CVE-2025-62859, let a malicious peer stall a node’s block processing. Affected versions cleared their download state for a compact block before checking for witness malleation. If that check failed, the node asked the same peer for the full block and waited up to 10 minutes. An attacker who controlled a victim’s three high-bandwidth peers, or who targeted a node running with -blocksonly, could repeat the trick indefinitely. Eugene Siegel reported it in April 2025, and it was fixed in 29.2 and 30.0.
The second, CVE-2025-62860, affected nodes that set the non-default -whitelist option to an IP range. Because inbound Tor connections arrive from the local Tor daemon’s address, those nodes treated every Tor peer as trusted, lifting denial-of-service limits and privacy protections. The advisory says popular node vendors bundled Bitcoin Core with Tor and set exactly that kind of range, which “led to thousands of reachable mainnet nodes whitelisting all incoming Tor connections.” Martin Zumsande and Antoine Poinsot found it in September 2025 and also alerted Bitcoin Knots maintainer Luke Dashjr and several affected software providers. Fixes went into 28.3, 29.2 and 30.0.
Why the details are only coming out now
Bitcoin Core’s disclosure policy holds back medium and high-severity bugs until two weeks after the last affected release line reaches end of life. The 29.x line went end of life on Oct. 27, 2026, the day 32.x became the newest major release, and the three advisories followed exactly 14 days later. The project disclosed three other bugs, two involving memory growth and one an undo-file overflow, on Oct. 28.
The delay is deliberate. It gives operators about a year to upgrade before an attacker gets a public description of the bug. It also means anyone still running an end-of-life version is now exposed to flaws that are fully documented.
Who is still running affected versions
A Wednesday snapshot from the Bitnodes crawler counted 20,225 reachable nodes. Of those, 1,204 reported Bitcoin Core 28.0 to 28.2 and 682 reported 29.0 or 29.1, the releases hit by the high-severity bug. That is about 9% of the reachable network. Another roughly 2,000 nodes reported releases older than 28.0. Those predate the TRUC bug, but they are past end of life and still exposed to the compact block stall, and to the Tor flaw if they use -whitelist. About 12,300 nodes, or 61%, were on 30.0 or later.
The numbers come with caveats. Bitnodes only sees nodes that accept inbound connections, version strings are self-reported, and the roughly 2,000 Bitcoin Knots nodes in the snapshot are counted separately because the advisories do not say which Knots builds were affected. Large mining pools usually run their block-template nodes privately, so the crawl says little about how many miners updated. Pools also had a strong reason to move early, since a node that cannot build templates cannot find blocks.
For node operators, the project’s lifecycle page sets out the practical point: 28.x and 29.x no longer receive security fixes, and 30.x is the oldest maintained line. The disclosures follow LNbits’ decision to disable its hosted instances after attacks earlier this month, a separate case on the Lightning side.
FAQ
Could these bugs be used to steal bitcoin?
The advisories describe stalled block processing, failed block templates and weakened peer protections. None of them describes a way to take coins or change consensus rules, and none reports exploitation.
Which Bitcoin Core versions have the fixes?
Version 30.0 and later fix all three, as does 29.2 and later on the 29.x line. Version 28.3 fixed the mining and Tor bugs but not the compact block stall. Both the 28.x and 29.x lines are now end of life.
Why was the mining bug rated high severity?
Because a chain reorganization could leave an affected mining node unable to produce valid block templates until it was restarted, which directly stops that miner from finding blocks.
Disclaimer: This article is for informational purposes only and does not constitute financial advice.
