Bitcoin Core Discloses High-Severity Mempool Bug That Silenced Miners
Bitcoin Core disclosed three patched vulnerabilities on Nov. 10, 2026, led by CVE-2025-62861, a High-severity mempool bug that left mining nodes silently unable to build block templates after a chain reorg. Patches shipped in October 2025.
A chain-reorg edge case in TRUC transaction logic could leave a node connected, synced, and useless, producing nothing until restarted.
Key takeaways
- CVE-2025-62861, rated High severity, caused mining nodes running Bitcoin Core 28.0-28.2 or 29.0-29.1 to lose the ability to build block templates after a chain reorganization, requiring a manual restart to recover.
- Bitcoin Core held disclosure for 396 days after patches shipped in October 2025 (versions 28.3, 29.2, and 30.0), waiting until the last affected release line reached end-of-life on October 27, 2026.
- No funds were ever at risk and no active exploits are reported, but any operator still on an affected version needs to upgrade immediately.
Bitcoin Core publicly disclosed three patched security vulnerabilities on November 10, 2026, per the Bitcoin Core security advisories index. The lead bug, CVE-2025-62861, is the only High-severity entry in the batch and the one with the sharpest operational edge: a miner's node could silently lose the ability to produce blocks, with no obvious alarm, until someone noticed and restarted it.
The Bug: Reorg Logic Breaks the Mempool
The root cause sits in TRUC (version 3 transaction) sibling-eviction logic, introduced in Bitcoin Core 28.0. During a chain reorganization, the node re-admits displaced transactions to the mempool. The sibling-eviction rule misfired during that re-admission step, evicting a transaction without also removing its descendants. The mempool landed in an inconsistent state, and the official advisory language is blunt about the result: the node "cannot produce blocks until it is restarted."
Security researcher Niklas Goegge discovered and responsibly disclosed the bug on September 26, 2025. Greg Sanders authored the fix, opening PR #33504 on September 29, 2025. Bitcoin Core 30.0 shipped October 10, 2025; 29.2 followed on October 14; 28.3 completed the backport set. Bitcoin Core then held the details for 396 days, standard practice under its embargo policy, releasing them only after the 29.x release line reached end-of-life on October 27, 2026.
This batch is separate from the AI-found vulnerabilities disclosed under Bitcoin Core's faster-track rules in October 2026. Do not conflate the two.
Why a Zombie Node Is the Right Threat Model
The failure mode here is insidious precisely because nothing looks broken from the outside. A node running 28.0-29.1 that hits a reorg stays connected, stays synced, keeps its peers happy, and reports no visible errors. It just stops building valid block templates. In a large mining operation running dozens or hundreds of nodes, a single zombie node quietly bleeds hashrate with no obvious alarm. The restart-to-recover requirement means any operator who didn't catch it immediately could have been leaking block-production time for the full duration of the event.
No one has publicly come forward to report they were affected during the exposure window. That's a good sign, but it carries two equally plausible interpretations: the patches reached operators fast enough to limit exposure, or any affected operators never connected their downtime to this specific bug. Neither fully closes the question.
The two medium-severity bugs in this batch deserve attention beyond the headline number. CVE-2025-62859, discovered by Eugene Siegel, let a malicious peer exploit witness data malleation in compact blocks to stall a victim node's block processing. An attacker controlling three of the victim's high-bandwidth compact-block peers could repeat the attack indefinitely, chaining 10-minute timeouts. CVE-2025-62860 is quieter but potentially broader: nodes using the non-default -whitelist setting inadvertently granted elevated trusted permissions to Tor connections. Thousands of nodes may have been affected, according to reporting from The Block. This one is a Sybil-resistance and DoS-protection failure that sits at the network's privacy layer.
The TRUC sibling-eviction bug is also a useful data point about where new vulnerabilities enter the codebase. This was not legacy debt. It was introduced with a new feature, v3 transaction relay, in a recent release. That's a normal pattern in any complex software, and it's the argument for conservative, review-heavy development at this layer. The fix required coordinated backports across three active release lines shipped simultaneously. The process worked as designed.
What Operators Need to Do Now
Anyone running Bitcoin Core 28.0-28.2 or 29.0-29.1 is on an end-of-life release line and exposed to all three bugs. Upgrade to 28.3, 29.2, or any version in the 30.x series or later. The Bitcoin Core security advisories index carries the full list of affected versions and patch releases.
The falsifiable claim embedded in the embargo narrative is this: Bitcoin Core's 396-day hold was justified because no exploit occurred during the window. If evidence surfaces that CVE-2025-62861 or either medium bug was actively used to suppress a specific pool's block production during the embargo period, the "caught before harm" framing collapses and the length of the hold becomes a liability rather than a feature. Watch the advisory language: "no known exploits in the wild" is the load-bearing fact.
Sources
Frequently Asked Questions
What is a chain reorganization, and why does it trigger this bug?
A reorganization happens when a competing chain with more accumulated proof-of-work replaces the current tip. The node un-confirms recent blocks and re-adds their transactions to the mempool. CVE-2025-62861's sibling-eviction logic misfired specifically during that re-admission step, leaving the mempool in a state from which the node could not construct a valid block template.
How does Bitcoin Core decide when to disclose a security vulnerability?
The standard policy holds details until all actively maintained release lines carrying a fix have shipped, then waits until the last vulnerable release line reaches end-of-life. That's the gap here: patches in October 2025, disclosure in November 2026. Bitcoin Core also updated its policy recently to allow faster disclosure for bugs deemed easily discoverable, which is how the earlier AI-found batch moved on a shorter timeline.
Do these bugs put funds at risk?
No. None of the three bugs can be used to steal coins or create new bitcoin. The risks are operational: a mining node may silently lose block-building capability, a node may grant unintended trust to Tor connections, and a node may have its block processing stalled by a malicious peer. Operational exposure, not monetary exposure. Upgrade anyway.
