Bitcoin Core disclosed three security flaws in November 2026 that it had fixed about a year earlier. The most serious one, rated High, stopped mining nodes from building valid block templates after a chain reorganization.
Bitcoin Core is the reference implementation of the Bitcoin protocol. Nodes on the network use this open-source software to check and relay transactions and blocks. Miners and pools also use it to build block templates from unconfirmed transactions in the mempool, the network's waiting area. As a rule, the project discloses vulnerabilities with a delay. First, the fix ships in a release. The description follows only once the affected versions are outdated. Fixes shipped across versions 30.0, 29.2 and 28.3 from October 2025. The three advisories carry the identifiers CVE-2025-62861, CVE-2025-62859 and CVE-2025-62860. CVE-2025-62861 carries a High rating, the other two a Medium rating. Therefore, the project published the advisories only 14 days after support ended for the 29.x line, the last vulnerable one.
Subscribe to our newsletter
The best articles of the week, directly delivered into your mailbox.
How a reorganization could stall mining nodes
The High flaw, CVE-2025-62861, affects versions 28.0 to 28.2 and 29.0 to 29.1. Niklas Goegge reported it in September 2025. It originates in TRUC, short for Topologically Restricted Until Confirmation, also known as v3 transactions. This mempool policy sets strict limits on how unconfirmed transactions may depend on each other. 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 try to add a second child to a TRUC parent transaction. If it pays enough in fees, it replaces the existing child.
The bug surfaced during a reorganization (reorg for short). In such an event, 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`. However, the sibling eviction branch did not respect this flag. It ran anyway. As a result, the rule evicted a transaction while its descendants stayed in the mempool. The mempool then held transactions that spent outputs that did not exist. Consequently, the validity check failed whenever the node built new block templates.
Affected miners could only produce valid templates again after restarting the node. That is because a restart reloads the mempool in a consistent state. Still, the advisory for CVE-2025-62861 names no workaround other than the update. Greg Sanders delivered the fix with PR #33504, which the project merged into the main branch in October 2025. In addition, the project backported it to the 28.x, 29.x and 30.x lines. Yet the flaw only hit template creation. Because TRUC is a mempool rule and not a consensus rule, the bug did not touch consensus.
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. Nodes use this shortened format to pass new blocks to each other. Affected versions cleared the download state of such a block before they checked for witness malleation. This term means an after-the-fact change to the witness data. If this check failed, the node requested the data again from the same peer via `GETDATA`. The timeout was 10 minutes. So a malicious peer announcing a compact block first could 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. PR #32646, merged in June 2025, finally 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 with the IP address of the Tor daemon. That is the local service that forwards traffic from the anonymity network. If this address fell within an IP range allowed via `-whitelist`, all inbound Tor peers thus 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. In 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. Meanwhile, the Tor flaw required a configuration that departs 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. The fixes entered the code from June to October 2025. Then, in October 2025, Bitcoin Core 30.0, 29.2 and 28.3 shipped with the corrections.
The end of support set the timing of the disclosure. Support for 29.x, the last vulnerable version line, ended on October 27, 2026. 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 on the middle levels. The time span for CVE-2025-62859 stands out. Siegel reported the flaw in April 2025, and the project merged the fix in June 2025. Nevertheless, it became public only just over 18 months after the report.
What the Bitcoin Core security 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, but they 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. For example, it is unclear 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. Additionally, there is no exact count of nodes affected by the Tor flaw. The record does show that the project fixed and shipped all three bugs just over a year before disclosure.
