Bitcoin Core Discloses Bug That Can Stall Wallet Confirmations

Bitcoin can keep producing blocks while your wallet stops seeing them. That is the useful distinction in Bitcoin Core’s newly disclosed bug: before paying more to hurry a transfer, check whether the software watching it is keeping up.

The November 10, 2026 security advisory describes CVE-2025-62859, a medium-severity flaw affecting Bitcoin Core before versions 29.2 and 30.0. A malicious peer—another computer connected to a node—could stall that node’s block processing under certain conditions.

How a wallet can fall behind

A node checks Bitcoin transactions and blocks. A wallet connected to it depends on that view to learn which payments have confirmed. A confirmation means a transaction has been included in a block, with subsequent blocks adding further confirmations.

The flaw involves compact blocks, a bandwidth-saving way for nodes to share new blocks. In affected software, a failed check on altered witness data—the transaction data used to prove spending authorization—could send the node back to the same peer to request the block, with a ten-minute timeout.

The advisory says an attacker could repeat the stall indefinitely if it controlled all three of the victim’s high-bandwidth peers, or if the victim used the -blocksonly setting.

For a holder, the practical consequence is a potentially stale picture of payments. A wallet relying on the affected node could lag behind what the network has already confirmed. That consequence follows from the node’s role; the advisory does not identify a particular wallet app or exchange experiencing delays.

The news is the disclosure; the fix is older

Bitcoin Core’s official announcements date version 30.0 to October 10, 2025 and version 29.2 to October 14, 2025. Both contain the fix identified in the advisory. The 29.2 release notes also list the relevant witness-mutation check, patch #32646.

Those version numbers mark where this particular fix arrived. They are not a recommendation to install an old release today. The advisory says the last vulnerable release line reached end of life on October 27, 2026; an operator should choose a currently supported release and follow its upgrade instructions.

There is a second reason to plan the update properly. The 30.0 release notes say legacy BDB wallets can no longer be loaded directly and require migration to the newer descriptor format. If your node also stores an old wallet, read the migration instructions and check your backups before changing versions. An unattended node update and a wallet-format migration deserve different levels of preparation.

What holders should check before spending more

My first move would be to identify whose node the wallet uses. Owning the keys and operating the infrastructure that reports confirmations are separate jobs.

• Your own node: check its version and whether its latest processed block is advancing. If it is behind, investigate synchronization and upgrade status before treating the displayed delay as a fee problem.
• A wallet provider’s backend: look for the provider’s service notice or ask whether its Bitcoin backend is affected. Updating a phone app does not establish which node version the provider runs.
• An exchange deposit: check the exchange’s deposit status and confirmation requirements. A delay alone does not diagnose this vulnerability.

Raising a transaction fee can make an unconfirmed transaction more attractive to miners. It cannot repair the software your wallet uses to observe the chain. That makes a quick backend check worthwhile before paying for a solution to the wrong problem.

The disclosure gives holders a maintenance question, not a reason to move coins to a new address. Keep recovery phrases out of any supposed “security update” website; the relevant action is checking and maintaining the node software.

Illustration: generated editorial still life with an authentic Bitcoin mark composited for identification; it does not depict an observed attack.