Bitcoin Core disclosed three previously patched security vulnerabilities on November 10, 2026, including a High-severity flaw that could stop an affected mining node from creating valid block templates after a blockchain reorganization. Two Medium-severity issues could delay block processing or mistakenly grant incoming Tor connections trusted-peer permissions. All three were addressed in releases first distributed in October 2025; the new development is the public disclosure of their technical details, not the discovery of an ongoing network-wide attack.
The Bitcoin Core mining bug is tracked as CVE-2025-62861; the other disclosures concern CVE-2025-62860 and CVE-2025-62859. Their consequences differ significantly, as do the configurations and software versions exposed. Bitcoin Core’s reports describe potential failures, but do not establish that these vulnerabilities were exploited against the live network.
What Are the Three Bitcoin Core Vulnerabilities?
The official disclosures distinguish a block-template failure, an unintended trust exemption for Tor connections, and a block-download stall. These should not be grouped together as a single “Bitcoin hack.”
| CVE | Project severity | Potential impact | Key affected circumstances |
|---|---|---|---|
| CVE-2025-62861 | High | An inconsistent mempool can prevent an affected mining node from building valid block templates until restart. | Bitcoin Core 28.0–28.2 and 29.0–29.1 after a qualifying chain reorganization. |
| CVE-2025-62860 | Medium | Incoming Tor peers may inherit trusted-peer exemptions from denial-of-service and privacy protections. | Vulnerable versions using a non-default -whitelist IP range that includes the Tor daemon. |
| CVE-2025-62859 | Medium | A malicious compact-block announcement can stall block processing for up to 10 minutes, potentially repeatedly. | Versions without the fix introduced in 29.2 or 30.0, under particular peer or -blocksonly conditions. |
CVE-2025-62861: How Could a Reorganization Stop a Miner?
The High-severity issue concerns the difference between Bitcoin’s mempool policy and its consensus rules. A mempool holds unconfirmed transactions that a node may include in a future block. Under BIP 431, version 3 transactions—called Topologically Restricted Until Confirmation, or TRUC—face additional relay restrictions, including limits on unconfirmed parents and descendants. Those restrictions are not rules that invalidate an otherwise valid block.
During a chain reorganization, blocks from a superseded branch are disconnected and their transactions may return to a node’s mempool. Bitcoin Core normally restores them with a setting called bypass_limits=true so that ordinary mempool admission restrictions do not interfere. However, the “sibling eviction” mechanism for TRUC transactions continued to run even during this restoration process.
According to the Bitcoin Core advisory for CVE-2025-62861, the defect could remove a reintroduced transaction while leaving transactions that depended on it in memory. The resulting mempool was internally inconsistent: descendants referred to outputs whose parent transaction was no longer there. A mining node attempting to assemble a candidate block would then fail its own validity check, preventing it from producing a usable block template.
Restarting the affected node could reconstruct a consistent mempool, but was only a recovery measure, not a substitute for installing the fix. The correction, merged as Bitcoin Core pull request #33504, prevents the sibling-eviction rules from running when the reorganization process explicitly bypasses policy limits. The vulnerability was reported by Niklas Goegge on September 26, 2025.
This was a possible disruption to an affected miner’s block-template creation, not a change to Bitcoin’s consensus rules. The disclosure does not show that every miner could be halted simultaneously, that coins could be created outside Bitcoin’s issuance rules, or that an actual network-wide outage occurred.
CVE-2025-62860: Why Were Some Tor Connections Treated as Trusted?
The second issue involved Bitcoin Core’s optional -whitelist configuration. Operators can designate trusted peers that receive exemptions from certain anti-abuse limits and privacy safeguards. For an incoming connection carried by Tor, Bitcoin Core could see the IP address of the local Tor daemon rather than a distinct remote peer. If the operator’s whitelist covered that proxy address, unrelated incoming Tor peers could unintentionally inherit trusted status.
The CVE-2025-62860 advisory says that combinations of bundled software and network settings caused thousands of reachable Bitcoin mainnet nodes to whitelist all incoming Tor connections. That figure comes from the project’s disclosure; it is not a count of confirmed compromises or successful attacks. Nodes that never enabled the non-default -whitelist setting were not affected by this specific bug.
Martin Zumsande and Antoine Poinsot reported the issue in September 2025. The fix prevents inbound Tor connections on onion binds from receiving whitelist permissions. Operators should still inspect their effective networking settings, especially when Tor is launched by a separate application or bundled node package.
CVE-2025-62859: How Could a Peer Delay Block Processing?
The third vulnerability affected compact-block relay, a bandwidth-saving method of announcing blocks between nodes. Bitcoin Core could clear a compact block’s download state before completing the check for altered witness data. When that check failed, the node requested the block again from the same peer using GETDATA, with a timeout of up to 10 minutes.
The official CVE-2025-62859 advisory explains that a malicious peer announcing the compact block first could exploit this sequence to stall a victim’s processing of a new block. A repeated stall was possible if the attacker controlled all three of the victim’s high-bandwidth peers, or when the victim used -blocksonly mode. This is a conditional block-processing disruption, not proof that the attacker could rewrite the blockchain.
Eugene Siegel reported the flaw on April 28, 2025. Its fix was included in Bitcoin Core 30.0 and the 29.2 maintenance release. Unlike the other two advisories, the compact-block fix was not included in the 28.3 maintenance release.
Which Bitcoin Core Versions Fix All Three Flaws?
The version distinction matters: some releases fixed the mining and Tor problems but not the compact-block issue. The table summarizes the three November disclosures only; it is not a complete security assessment of any release.
| Bitcoin Core branch/version | Three-disclosure status | Maintenance status in November 2026 |
|---|---|---|
| 28.0–28.2 | Exposed to the mining and compact-block bugs; Tor bug depends on whitelist configuration. | End of life |
| 28.3 and later 28.x | Mining and Tor fixes included; compact-block stall remains unpatched in this branch. | End of life |
| 29.0–29.1 | Exposed to all three, with the Tor issue requiring the relevant configuration. | End of life |
| 29.2 and later 29.x | All three fixes included. | End of life since October 27, 2026 |
| 30.0 and newer | All three fixes included. | 30.x, 31.x and 32.x are maintained major branches. |
Bitcoin Core released 30.0 on October 10, 2025, and 29.2 on October 14, 2025. The project’s software lifecycle policy identifies 29.x as end-of-life on October 27, 2026. As of this disclosure period, its maintained release branches include 30.x, 31.x and 32.x; the 32.1 release notes document the newest major line. A patched but end-of-life build is not equivalent to a currently supported build.
Why Did Bitcoin Core Disclose Fixes More Than a Year Later?
The timing follows Bitcoin Core’s published security disclosure policy. Under its regular schedule, Medium- and High-severity vulnerabilities are disclosed two weeks after the final affected release branch reaches end of life. The relevant 29.x branch reached that milestone on October 27, 2026; detailed advisories followed on November 10.
Bitcoin Core also now allows faster publication for vulnerabilities considered easy to rediscover, including with simple automated analysis. That exception should not be confused with the timeline documented for these three older reports. Public disclosure date and first patched release date must be kept separate.
What Should Miners and Node Operators Do?
- Check the exact running version. Determine whether the node uses a vulnerable release, including older 28.x and 29.x builds. Do not assume that installing 28.3 closes all three issues.
- Move to a supported, appropriate maintenance release. Review compatibility with mining infrastructure, wallet software, operating systems and other dependent applications. Plan a clean shutdown and recovery process before upgrading a production node.
- Review network configuration. Check whether the node uses
-whitelist, an inbound Tor proxy or-blocksonly. These settings change exposure to the Medium-severity issues but are not alternatives to patched software. - Verify installation files. Obtain binaries and checksums from the official Bitcoin Core download page and follow its signature-verification instructions. After restarting, confirm the version, peer connectivity, block synchronization and mining-template functionality where applicable.
Does This Mean Bitcoin Was Hacked?
No confirmed theft, inflation vulnerability or network-wide chain compromise is established by these three advisories. They describe specific software behaviors that could undermine mining availability, block propagation or node-level protections under defined conditions. That distinction is especially important for ordinary Bitcoin holders who do not operate Bitcoin Core themselves: these disclosures alone do not require moving funds or revealing recovery phrases.
These November disclosures are also separate from the three node memory and storage vulnerabilities made public in October 2026, covered in Creeptoz’s earlier Bitcoin Core security report. Treating the two disclosure batches as the same event would obscure their different CVE identifiers, mechanisms and patch histories.
The bottom line: the November 10 disclosures reveal a serious historical mining-template bug and two narrower node-security problems, but fixes have been available since October 2025. For operators, the priority is to verify the release they actually run, understand their configuration-specific exposure and stay on maintained software—not to mistake a delayed security advisory for a newly successful attack on Bitcoin.