Bitcoin Core Discloses Flaw That Halts Block Template Creation

Bitcoin Core disclosed a vulnerability on Tuesday, Nov. 10, 2026, that can leave affected nodes unable to create block templates after a chain reorganization. The flaw, tracked as CVE-2025-62861, requires a manual restart before template generation resumes.

The affected software spans a wide band of production deployments: Bitcoin Core versions 28.0 through 28.2 and 29.0 through 29.1. Security researcher Niklas Goegge discovered the bug. Fixed releases appeared in October 2025, more than a year before the project made the details public this week.

That gap is deliberate. Bitcoin Core routinely withholds vulnerability specifics until enough operators have upgraded, so the disclosure itself carries a message: anyone still running 28.x or 29.x is now running known-vulnerable code.

What does the flaw actually do?

The mechanics are narrow but operationally meaningful. After a reorganization — when the chain's best-block tip changes and nodes reorganize their view of recent history — a mempool inconsistency can take hold on an affected node. That inconsistency blocks the node from creating block templates.

Block templates are the scaffolding miners build on. A mining node that cannot produce a template cannot mine. The failure mode does not corrupt the chain or move funds. It halts the affected operator's own participation in block production until someone restarts the node.

For a solo miner, that means downtime and lost block revenue. For a pool running affected versions, it means degraded hashpower utilization until an operator intervenes. The chain itself keeps moving, built by everyone else.

Who needs to act now?

The practical exposure question is straightforward. Anyone operating a node on Bitcoin Core 28.0 through 28.2, or 29.0 through 29.1, in any capacity that depends on template creation should treat an upgrade as immediate. The fixes have existed since October 2025, so remediation costs nothing but operational discipline.

The disclosure does not describe exploitation in the wild. But the vulnerability class is worth noting for what it reveals: correctness bugs that surface only after reorganizations are among the hardest to catch in routine testing, because reorgs of meaningful depth are rare and hard to reproduce.

A reorganization deep enough to trigger the failure may itself coincide with network stress — exactly the moment an operator least wants a node that has quietly stopped performing its core function. The restart requirement adds human latency to what would otherwise be an automated recovery.

What does this change for operators?

Not much for those who upgraded. Everything for those who did not. The public identifier, the affected version list and the fix timeline are now on the record, which converts a theoretical patch into a documented, citable reason to update.

It also continues a disclosure pattern the project has refined over years: fix first, publish later, give stragglers a runway. Goegge's find and the October 2025 fixes fit that template.

Operators still on affected builds face a simple deadline of their own making — the window closes when a reorg finds them first.