Bitcoin Core has published the official disclosure of CVE-2025-62861, a high-severity flaw in the node software's transaction-relay logic that could leave mining operations hashing on stale block templates without any visible warning. The advisory credits security researcher Niklas Goegge with reporting the issue and traces it to a relay rule that fired at the wrong moment: during a chain reorganization, when it should have stayed silent.

Affected versions run from Bitcoin Core 28.0 through 28.2 and from 29.0 through 29.1. The fix shipped in October 2025, but the full technical details were withheld until November 2026 under the project's coordinated disclosure policy. The advisory names no outage and no affected operator; the exposure is historical. Mining hardware pointed at a node in the corrupted state would have kept hashing, but on the last template it received, so new transactions and their fees would have gone unclaimed until someone noticed.

How a reorganization can orphan a transaction

A reorganization happens when a node abandons its current chain tip for a competing, heavier branch. The transactions in the disconnected blocks remain valid, so Bitcoin Core places them back into the mempool, its holding area for unconfirmed transactions. Because those transactions were already confirmed in a valid block, the node re-adds them with a flag called bypass_limits, which switches off the usual anti-spam and topology checks. The purpose is to restore the pool faithfully, not to re-judge transactions that have already passed consensus.

One of the checks that should have been switched off concerns version-three, or TRUC, transactions. Under BIP 431, a TRUC transaction may have at most one unconfirmed parent and one unconfirmed child. That is a relay policy, not a consensus rule: a block can legitimately contain a TRUC parent with several children, even though no node would accept that shape into its mempool from the network. That same boundary between policy and consensus set the boundary of the bug itself: CVE-2025-62861 could corrupt a node's mempool and stall its template output, but it could not create an invalid block or alter the chain's rules.

Since version 28.0, Bitcoin Core has enforced the one-child limit through a mechanism called sibling eviction. When a new transaction would give a TRUC parent a second unconfirmed child, the node treats the existing child as a replacement candidate and, if the newcomer pays enough in fees, evicts it under replace-by-fee rules.

The bug was that sibling eviction ran even when bypass_limits was set. A reorg that restored a TRUC parent with multiple children — a shape perfectly valid inside the disconnected block — could trigger eviction of one restored transaction while leaving in the pool the transactions that spent its outputs. The mempool then held children whose parent no longer existed anywhere: not in the chain, and not in the pool.

Greg Sanders' fix gated the TRUC checks on bypass_limits, so eviction no longer runs during reorg restoration. The associated pull request, PR #33504, also added the test scenario the original code lacked: transactions arriving from disconnected blocks rather than from peers.

What a stalled template looks like from the mining side

A node hands work to mining software through getblocktemplate, which assembles a candidate block, runs it through the node's own validity check, and returns the previous block hash, the chosen transactions, and the next height. With a parentless transaction sitting in the pool, the assembled candidate failed that check, so the call could not return fresh work.

From the outside, the node looked healthy:

• Process running
• Peer connections open
• Chain tip advancing
• Mempool accepting new transactions

What was actually broken:

• The template request returns an error
• Hashers keep working on stale work
• No block can be found on the current tip
• The state persists until the node is restarted

Everything a generic monitoring dashboard watches would have stayed green. The network gave no signal back either: the chain tip kept advancing — blocks were still being found, just not by this operation — so the cost fell on the stalled miner alone, in hashing that could not produce a block on the current tip and in fees it would otherwise have claimed. The one thing a miner needs from the node — a current template — was the one thing it had stopped producing.

Restart, patch, and end of life

Restarting the node reloads the mempool from disk in a consistent state, which clears the symptom. It does nothing about the cause: the next reorg carrying the same transaction shape could stall the node again.

The underlying flaw was removed in three releases. Version 30.0 shipped with the fix on October 10, 2025, and backports followed in 29.2 and 28.3. From the private report to the last of those releases took three weeks:

Both backport branches have since left support. Bitcoin Core's maintenance policy covers the three most recent major versions — currently 30.x, 31.x and 32.x — and 29.x reached end of life on October 27, 2026. An operator who answered the original failure with a restart and nothing more is now running unsupported code, with a public description of exactly which transaction shape triggers it.

Why the advisory waited 396 days

From the first fixed release to the detailed advisory took 396 days, and the disclosure landed exactly two weeks after 29.x went end of life. Neither number is a coincidence. Bitcoin Core's disclosure policy holds medium- and high-severity details until two weeks after the last affected release is no longer supported, with a pre-announcement two weeks before that, timed to coincide with a new major release.

The embargo covered the explanation, not the code. The pull request has been public since September 29, 2025, and the 28.3 and 29.2 release notes listed a mempool fix at the time. What stayed private for a year was the write-up connecting the patch to a reproducible mining stall.

The policy does provide a faster route. Bugs classified as easily discoverable — which the project defines as findable with minimal effort — receive an immediate point release and advisory with no embargo. This one went through the standard timetable, so the maintainers did not consider it trivial to find. It was published alongside two other high- and medium-severity advisories the same day, covering a block-processing stall and a Tor permissions error; all three were fixed in the same October 2025 release cycle. Any build new enough to carry the mempool patch therefore carries the other two fixes as well.

The slower track embodies its own assumption: that operators upgrade inside the year-long window, so that by the time the trigger is described in public, nobody vulnerable is still listening.

What to monitor instead of uptime

For a mining operation, the useful check is not whether the node is alive but how old its most recent successful template is. A process that is running, connected and synced can still have stopped delivering work, and this bug was one way for that to happen silently. Build version belongs in the same check, because a node that is current on templates today can be a node that is out of support tomorrow.

Backup template sources need the same question asked of them. A failover node on the same release and the same mempool policy would have hit the same reorg and the same stall; two running processes are not two independent sources of work. Only a node on a different, patched build would have kept the operation mining, and only an operator who tested that under a simulated reorg would have known it in advance.