Bitcoin Core has publicly disclosed a high-severity vulnerability, CVE-2025-62861, that could have prevented mining nodes from producing new blocks following a chain reorganization. The flaw was silently patched more than a year ago, and no exploitation in the wild has been confirmed, but the disclosure underscores how quietly critical bugs can move through Bitcoin’s open-source development pipeline before the wider community learns of them.
What Bitcoin Core fixed and why the mining risk mattered
Bitcoin Core is the reference software implementation that the majority of full nodes and mining infrastructure use to validate transactions and build block templates. It is distinct from the Bitcoin network itself; the network continues so long as enough nodes run compatible software, but a bug in Core can still create serious operational problems for miners who depend on it.
According to the official Bitcoin Core advisory, CVE-2025-62861 was introduced in version 28.0 alongside a feature called TRUC, also known as v3 transaction relay. During a chain reorganization, the TRUC sibling eviction logic was not gated on the bypass_limits flag that normally applies during re-addition of transactions to the mempool. The result: transactions spending outputs that no longer existed could remain in the mempool, corrupting its state and preventing block template creation until the node was restarted.
The practical risk was targeted but meaningful: a mining node running an affected version that encountered a reorg could silently lose the ability to assemble new blocks, missing out on block rewards until an operator noticed and restarted the process. Because chain reorganizations are a normal, if infrequent, part of Bitcoin’s operation, the scenario was not theoretical.
Security researcher Niklas Goegge reported the flaw on September 26, 2025. Developer Greg Sanders opened fix PR #33504 three days later; it was merged on October 2, 2025, and backported across three release lines: v30.0 on October 10, v29.2 on October 14, and v28.3 on October 17, all in 2025.
How a mining interruption could affect the Bitcoin network
Miners compete to append new blocks to Bitcoin’s chain roughly every ten minutes. When a node cannot build a valid block template, it cannot participate in that competition. A single affected node going offline harms only its operator; a wider failure across many nodes running the same vulnerable software version could, in theory, slow the pace of transaction confirmations for the broader network.
The Bitcoin Core advisory confirmed no exploitation occurred, and the network showed no disruption during the window in which the bug existed. Still, the scenario illustrates the operational dependency that miners and node operators have on Core’s codebase, particularly when new transaction relay features like TRUC are introduced.
CVE-2025-62861 was not disclosed in isolation. Unchained Crypto reported that Bitcoin Core simultaneously disclosed two additional medium-severity vulnerabilities: CVE-2025-62860, in which Tor inbound connections were incorrectly granted whitelist permissions affecting a large number of mainnet nodes, and CVE-2025-62859, in which a malicious peer could stall block processing through compact block abuse. All three fixes had already shipped before the November 10, 2026 disclosure date.
The crypto community’s reaction on X was measured, with most commentators noting the patches had been available for over a year. @TFTC21 wrote that the worst bug, rated High, could leave a mining node unable to build blocks after a reorg until it was restarted, and urged anyone still running anything older than 29.2 or 30.0 to be aware.
Bitcoin Core held the public disclosure for approximately 396 days after fixes shipped, waiting specifically until the vulnerable 29.x release line reached end of life on October 27, 2026. That interval is notably long even by the project’s own historical standards for responsible disclosure.
The timing also coincides with a policy update from Bitcoin Core: the project now intends to disclose vulnerabilities that are discoverable by AI tools immediately after patching, rather than holding them under extended embargo. Decrypt reported this shift reflects growing concern that large language models could assist malicious actors in rediscovering known flaws from patch diffs before operators have had time to upgrade.
What node operators, miners, and users should do next
Operators running Bitcoin Core versions 28.0, 28.1, 28.2, 29.0, or 29.1 are running software that contains the high-severity mining-node flaw. The fixed releases are v28.3, v29.2, and v30.0. Node operators and mining infrastructure teams should review the official CVE advisory and their internal deployment procedures before upgrading, as any major node software update carries its own operational risk and should be tested in staging environments first.
Users who do not operate Bitcoin Core directly or manage mining infrastructure have no immediate action to take. The Bitcoin network itself was not disrupted, and transaction confirmations were not affected during the period the vulnerability existed.
The broader security picture for Bitcoin infrastructure has drawn attention recently, as high-profile security breaches in the crypto industry have kept exchange and custody operators on alert. The Bitcoin Core disclosure is a different category of risk, concerning open-source node software rather than custodial systems, but it reinforces the case for timely software updates across all Bitcoin-adjacent infrastructure.
Mining operators in particular should treat the two medium-severity CVEs as seriously as the high-severity one. The Tor permission misconfiguration (CVE-2025-62860) and the compact block stalling attack (CVE-2025-62859) both affected production mainnet nodes and were patched in the same release cycle. Running the latest supported release addresses all three simultaneously.
The new AI-discoverable-bug disclosure policy from Bitcoin Core signals that future patch cycles may move faster from fix to public announcement. For mining operations and node operators, that shortens the window between a patch becoming available and the vulnerability details becoming widely known, making rapid upgrade cadences more important than they have historically been.
