Bitcoin Core discloses three bugs, one that can halt mining

Bitcoin Core developers disclosed three software bugs on November 10, 2026. One carries a high-severity rating and can stop a mining node from building blocks after a chain reorganization. All three were already patched.

The advisories come from the Bitcoin Core project, which maintains the software most of the network runs. The worst of the three, tracked as CVE-2025-62861, was reported by security researcher Niklas Goegge on September 26, 2025, according to the project's own timeline. No funds were at risk. No exploit has been reported in the wild.

Bitcoin Core is the reference software that checks transactions and blocks for most of the network's nodes. When a bug sits in it, the question is rarely about theft and more about whether nodes keep agreeing on the same chain and keep doing their jobs. A mining node that cannot build a template is still honest. It just goes quiet.

What the high-severity bug does

CVE-2025-62861 could freeze a mining node after a chain reorganization, leaving it unable to assemble a valid block. A reorg happens when the network briefly follows two competing versions of the latest blocks, then settles on one. Transactions from the discarded blocks flow back into the waiting pool, the mempool, to be mined again. In the affected versions, that return step could leave the pool in a state the node could not work with.

Here is what that meant in practice. The node stayed online. It stayed synced. But it could no longer build a block template, the draft of the next block a miner tries to solve. It behaved like an assembly line that keeps running while its parts list no longer matches the bins. Nothing crashes. Nothing gets built either. The only cure was a restart, which reloads the pool cleanly.

A block template is the miner's to-do list. It bundles the fee-paying transactions a miner wants in the next block, ordered by what pays best, ready for the hardware to grind on. Without a fresh template, costly machines keep running but earn nothing. For a large operation even a short gap is measured in real dollars, which is why the bug drew the high-severity label despite touching no one's coins.

The cause was a piece of logic called sibling eviction, added in version 28.0, which decides when one pending transaction can bump another out. During a reorg the software is meant to skip those policy checks while it restores transactions. A gap let one check run anyway. Greg Sanders wrote the fix, pull request 33504, which closes it.

Two medium-severity flaws came with it

Two other bugs shipped in the same batch, both rated medium. CVE-2025-62859 let a hostile peer stall a node's block processing for about 10 minutes at a stretch by sending a malformed block announcement. Eugene Siegel reported it on April 28, 2025. A patch followed weeks later.

CVE-2025-62860 was narrower. It touched only operators who paired an optional setting, called whitelist, with incoming Tor connections, a setup few use. Those peers wrongly gained trusted status, which stripped away some spam and privacy defenses. Crypto Briefing reported that thousands of reachable nodes ran that configuration, though the figure covers this bug alone.

Why the details came out now

Bitcoin Core withholds the full description of a bug until the releases it affects are retired. CVE-2025-62861 touched versions 28.0 through 28.2 and 29.0 through 29.1. The 29.x line reached end of support on October 27, 2026. Once that date passed, the project published the write-up, 396 days after Goegge first flagged it.

This is the project's second disclosure batch in a fortnight. A separate set of three CVEs, all dated October 28, 2026, covered memory growth and a reorg crash in older builds. Clusters like this follow the end-of-life schedule rather than signal that the code is failing. Old versions age out, and their held-back bugs get written up together.

That embargo is deliberate. Spelling out how a bug works hands node operators a map, and it hands attackers the same one. Holding the details until almost everyone has moved to a fixed release shrinks that window. Some developers argue for faster disclosure. Others fear copycats. The policy sits between them.

Who still needs to act

Anyone running Bitcoin Core 28.x or 29.x below the patched point should update. The fixed releases are 28.3, 29.2 and 30.0, all out since October 2025. For a home user checking their own payments, the practical risk was low. For a mining operation, a frozen template means idle machines and lost income until someone notices and reboots. The math behind how long it takes to mine a single bitcoin already leaves thin margins, so unplanned downtime stings.

What is not known is how many nodes still run the vulnerable builds, or whether any miner hit the bug in production before the fix landed. Neither the advisory nor the outlets covering it gave a node count for the mining flaw. The project said only that it saw no exploit.

None of this touches Bitcoin's monetary rules. The 21 million cap, the halving schedule and the proof-of-work that secures the chain all sit in consensus code these bugs never reached. What broke was plumbing: how a node manages its own copy of pending transactions. Plumbing failures are annoying and can cost a miner money. They do not rewrite the ledger.

What to watch

Watch the upgrade curve. A known share of the network tends to lag months behind each release, and a published write-up can turn a quiet bug into a tested one. Bitcoin's defenses get questioned often, usually over distant threats like whether quantum computers could break it. This was plainer: a bookkeeping slip that froze some miners and was fixed before most people heard of it. The next step for operators is dull and familiar. Update the software.