Bitcoin Core published details of three security vulnerabilities in November 2026, roughly a year after fixes for the flaws had already shipped. The most serious of the three, rated High, could stop mining nodes from producing valid block templates after a chain reorganization.

Bitcoin Core is the reference implementation of the Bitcoin protocol. Nodes across the network rely on this open-source software to validate and relay transactions and blocks, while miners and mining pools use it to assemble block templates from unconfirmed transactions in the mempool, the network's holding area for pending transactions.

As a matter of policy, the project discloses vulnerabilities only after a delay: the fix ships first in a release, and the technical description follows only once the affected versions have become outdated. The corrections for these flaws landed in versions 30.0, 29.2 and 28.3, all released in October 2025. The advisories carry the identifiers CVE-2025-62861, CVE-2025-62859 and CVE-2025-62860 — the standard identifiers under which publicly disclosed software vulnerabilities are catalogued. CVE-2025-62861 is rated High; the other two carry Medium ratings. Accordingly, the project published the advisories just 14 days after support ended for the 29.x line, the last vulnerable release series. The full texts are available in the official disclosure and in the project's security advisory index.

How a Reorganization Could Stall Mining Nodes

The High-severity flaw, CVE-2025-62861, affects versions 28.0 through 28.2 and 29.0 through 29.1. Niklas Goegge reported it in September 2025. The defect traces back to TRUC — short for Topologically Restricted Until Confirmation — also known as v3 transactions. This mempool policy imposes strict limits on how unconfirmed transactions may depend on one another, and its main purpose is to help layer-2 protocols such as the Lightning Network raise fees after the fact. Version 28.0 added a further rule called sibling eviction: a new transaction may attempt to attach a second child to a TRUC parent transaction, and if it pays enough in fees, it replaces the existing child.

The bug surfaced during a reorganization, or "reorg" for short — an event in which the network replaces the most recently added blocks with a different chain. Bitcoin Core first returns transactions from the disconnected blocks to the mempool with the flag bypass_limits=true. The sibling eviction branch, however, did not respect this flag and ran anyway. As a result, the rule evicted a transaction while its descendants remained in the mempool, leaving the mempool with transactions that spent outputs that no longer existed. Whenever the node then tried to build new block templates, the validity check failed.

Affected miners could produce valid templates again only after restarting the node, because a restart reloads the mempool in a consistent state. Even so, the advisory for CVE-2025-62861 names no workaround other than the update. Greg Sanders delivered the fix in PR #33504, which the project merged into the main branch in October 2025 and backported to the 28.x, 29.x and 30.x lines. The flaw affected only template creation: because TRUC is a mempool rule rather than a consensus rule, the bug did not touch consensus. Mempool rules such as TRUC are local policies each node applies to its own pending transactions, unlike consensus rules, which every node enforces on the shared chain.

Two Medium Flaws Affect Block Relay and Tor Peers

CVE-2025-62859 affects versions before 29.2 and before 30.0. Eugene Siegel had reported the vulnerability as early as April 2025. It sits in the handling of compact blocks, the shortened format nodes use to pass new blocks to one another. Affected versions cleared the download state of such a block before checking for witness malleation, a term for an after-the-fact change to the witness data. If the check failed, the node requested the data again from the same peer via GETDATA, with a timeout of 10 minutes — roughly the average interval between Bitcoin blocks. A malicious peer that announced a compact block first could therefore delay the victim's block processing by up to 10 minutes. Moreover, the attacker could repeat the attack without limit in -blocksonly mode or when controlling all three high-bandwidth peers, the small set of peers a node relies on for priority block announcements. PR #32646, merged in June 2025, fixed the bug.

The second Medium flaw, CVE-2025-62860, affects versions before 28.3, 29.2 and 30.0. Martin Zumsande and Antoine Poinsot reported it in September 2025, two weeks before Goegge reported the High flaw. In Bitcoin Core, inbound Tor connections appear under the IP address of the Tor daemon, the local service that forwards traffic from the anonymity network. If that address fell within an IP range allowed via -whitelist, all inbound Tor peers received whitelist permissions. These permissions lift DoS limits and protections against privacy leaks.

According to the advisory, "thousands" of reachable mainnet nodes had granted these rights to all inbound Tor connections. Often, providers that ship Bitcoin Core bundled with a Tor daemon had set the option. By contrast, the flaw never affected nodes without this optional, non-default setting. Since PR #33395, Bitcoin Core no longer considers inbound Tor peers when it assigns whitelist permissions.

The project rates both flaws as Medium. The delay in block processing was temporary, and attackers could repeat it at will only in specific setups, while the Tor flaw required a configuration that departed from the default.

Why a Year Passed Between Fix and Disclosure

Bitcoin Core deliberately separates the fix from the disclosure. The correction ships first in a regular release, and the project does not describe the vulnerability at that point; details follow later, once the affected versions are older or have reached end of support. This gives operators time to update.

For the three current advisories, the reports came in between April and September 2025, and the fixes entered the code from June to October 2025. Bitcoin Core 30.0, 29.2 and 28.3 then shipped with the corrections in October 2025. The end of support set the timing of the disclosure: support for 29.x, the last vulnerable version line, ended on October 27, 2026, and the advisories followed on November 10, 2026 — 14 days later.

The project's advisory index uses four severity levels: Critical, High, Medium and Low. All three advisories sit at the middle levels. The time span for CVE-2025-62859 stands out: Siegel reported the flaw in April 2025, the project merged the fix in June 2025, and the details became public only just over 18 months after the report.

What the Flaws Mean for Miners and Node Operators

The High flaw mainly affected miners and pools. Only nodes that went through a reorg and then had to build block templates triggered the bug. By contrast, the two Medium flaws hit ordinary nodes too, though each required a specific network situation or configuration.

Versions 30.0 and 29.2 fix all three bugs, and 28.3 fixes two of them. Since the end of October 2026, however, only versions from 30.x onward receive support. Anyone running 29.x or older therefore uses unsupported software, even with the backports.

The advisories leave several questions open. It remains unclear, for example, whether an attacker can deliberately create the reorg topology that triggers the High bug. Nor do the advisories say whether anyone ever exploited one of the three flaws, and there is no exact count of nodes affected by the Tor flaw. The record does show, however, that the project fixed and shipped all three bugs just over a year before disclosure.