Mentioned in This Article
1. Bitcoin Core news: three vulnerabilities made public
Bitcoin Core, the open-source software that runs most nodes on the Bitcoin network, disclosed three security vulnerabilities on November 10, 2026. The most serious, rated High severity, could prevent a mining node from producing blocks until it was restarted. All three flaws were fixed in Bitcoin Core 30.0 and 29.2, released in October 2025, more than a year before the details became public.
The three issues carry the identifiers CVE-2025-62861, CVE-2025-62860 and CVE-2025-62859. The first is classed as High severity, while the other two are classed as Medium. A CVE number is simply a standard catalog entry for a publicly known software flaw, giving developers, operators and security teams a shared reference when they discuss a specific bug.
The project waited until its last vulnerable release line, the 29.x series, reached end of life on October 27 before publishing the technical write-ups. The advisories do not state whether any of the three bugs was ever exploited on the live network.
Taken together, the disclosures touch three distinct parts of a node's job: managing the pool of transactions waiting to be confirmed, deciding how much to trust the peers it connects to, and processing new blocks as they arrive. Each is described in turn below.
2. What is Bitcoin Core and why do its bugs matter?
Bitcoin Core is the reference implementation of the Bitcoin protocol, the software that validates transactions and blocks, relays data between peers and, for miners, assembles the candidate blocks they try to add to the chain. Because a large share of the network runs it, a flaw in Bitcoin Core can affect many independent operators at once.
Nodes are the network's referees. Each one checks every block and transaction against the consensus rules and refuses anything that breaks them. Mining nodes take on an extra task: they gather unconfirmed transactions into a block template, which mining hardware then works on. If that template is invalid, the work spent on it is wasted, and the miner earns nothing until the problem is resolved.
That is why a bug that interferes with block templates is treated seriously even when it never touches the coins themselves. The High-rated issue disclosed this week is an example: it could knock a mining operation out of production at an unpredictable moment, triggered by an event the miner does not control.
3. How the disclosure timeline played out
The fixes for all three flaws first appeared in Bitcoin Core 30.0, released on October 10, 2025. Four days later the project shipped version 29.2, which carried the same patches for operators who preferred to stay on the older release line. The gap between those releases and this week's disclosure works out to 396 days.
Holding back technical details while vulnerable versions are still supported is a common practice in open-source security. It gives node operators time to upgrade before anyone can read a description of how to trigger the bug. Once the last affected line stops receiving updates, the project treats it as safe to publish the full explanation, on the basis that anyone still running unsupported software has been warned for months.
This week's advisories were also expected. On October 28, Bitcoin Core disclosed a separate group of three bugs that had been found with the help of artificial intelligence tools, and it published those without its usual embargo period. The release notes accompanying that earlier disclosure said that three further bugs fixed in version 30.0 would be made public in two weeks. The November 10 advisories fulfil that commitment.
4. A mempool rule that could break block templates
The most severe of the three problems sat in the mempool, the area of memory where a node keeps transactions that have been broadcast but not yet confirmed in a block. Miners draw on the mempool when they decide which transactions to include in their next block, usually favoring those that pay the highest fees.
The bug involved version 3 transactions, also known as TRUC transactions, short for Topologically Restricted Until Confirmation. TRUC transactions follow tighter rules than ordinary ones: an unconfirmed parent can have only one unconfirmed child. The design is meant to make fee bumping more predictable, which matters for applications such as payment channels that need to get transactions confirmed on time.
Bitcoin Core 28.0 introduced a rule called sibling eviction to go with this design. If a TRUC parent already has an unconfirmed child and a new, higher-paying child arrives, the node can drop the existing child and accept the new one, since the rules allow only a single child at a time.
The flaw surfaced during chain reorganizations. A reorganization happens when the network settles on a different sequence of recent blocks than the one a node had been following, so the node must roll back some blocks and return their transactions to the mempool. During that re-entry, the sibling eviction rule could misfire, removing a transaction that had been restored while keeping the transactions that depended on it.
That left the mempool in an inconsistent state, with child transactions whose parent was no longer present. When the mining node built a block template from that pool, the template failed validation. In the advisory's own description, the node could then fail to produce blocks until it was restarted.
The affected versions were 28.0 through 28.2 and 29.0 through 29.1. The issue was reported by Niklas Goegge in September 2025.
5. Which Bitcoin Core versions are affected?
Operators running Bitcoin Core 29.2 or 30.0 or any later release already have fixes for all three bugs. According to the timelines in the advisories, those two versions were the first to address every issue disclosed this week.
For the High-severity mempool bug specifically, the vulnerable range covers 28.0 to 28.2 and 29.0 to 29.1. Because the 29.x line reached end of life on October 27, nodes still running an older version in that series will not receive further patches and would need to move to a supported release to stay protected.
The practical guidance that follows from the disclosures is the same advice the project gives with every security release: keep node software current. Patches for all three flaws have been available for more than a year, so the advisories mainly serve as a record of what was fixed and why, rather than an emergency call to action for operators who have upgraded.
6. Whitelisting that extended trust to every Tor peer
The second vulnerability affected a narrower group: only nodes that used Bitcoin Core's optional whitelist setting. Whitelisting lets an operator mark certain peers as trusted, which loosens the protections the node normally applies to strangers, including denial-of-service limits and some privacy safeguards.
The problem arose with Tor, the anonymity network many node operators use to hide their IP addresses. When another node connects through Tor, the connection reaches Bitcoin Core by way of the local Tor service, so it appears to originate from the address of the Tor daemon running on the same machine. If an operator whitelisted the address range that included that daemon, every inbound Tor peer inherited the trusted permissions, not just the peers the operator intended.
This was not merely a theoretical misconfiguration. Vendors that bundle Bitcoin Core together with Tor had set up their products in exactly this way. The project said the result was that thousands of reachable nodes on Bitcoin's main network were whitelisting all incoming Tor connections.
Martin Zumsande and Antoine Poinsot reported the issue. In September 2025, Poinsot alerted Luke Dashjr, the maintainer of Bitcoin Knots, an alternative node implementation derived from Bitcoin Core, along with several of the affected providers, so they could address the configuration on their side.
7. Compact block handling and repeated stalls
The third vulnerability concerned compact blocks, a relay method that saves bandwidth. Instead of sending a complete block, a peer sends a condensed version that references transactions the receiving node very likely already has in its mempool. The receiver rebuilds the full block locally and requests only the pieces it is missing.
A malicious peer could abuse the way Bitcoin Core handled this process to stall a node's block processing. Under some configurations, the stall could be repeated indefinitely, holding the node back from keeping up with the chain for as long as the attacker continued.
For an ordinary node, falling behind delays its view of new transactions and blocks. For a mining node, it can mean working on an outdated chain tip, which wastes hash power. Eugene Siegel reported the issue in April 2025.
8. What the advisories leave unanswered
The most notable gap in the published material is exploitation. None of the three advisories says whether attackers ever used the flaws against real nodes, and the project has not offered an assessment either way.
The disclosures do, however, show how the work was spread across contributors. Four individuals are credited with reports across the three issues, and the reports arrived between April and September 2025, ahead of the October releases that fixed them.
The episode also highlights how much of Bitcoin's resilience depends on node software that can quietly ship fixes before the public learns the details. All three bugs were closed in releases that came out in October 2025, while the technical write-ups waited until no supported version remained exposed.
9. What comes next for node operators
With the 29.x line now retired, versions 29.2 and 30.0 mark the minimum releases that carry fixes for every flaw disclosed on November 10. Operators of mining pools, exchanges, wallet backends and personal nodes who have not upgraded since before October 2025 remain exposed to issues whose mechanics are now public.
Operators who use the whitelist option, particularly in packaged node products that run Tor alongside Bitcoin Core, have an additional reason to review their settings and confirm that trusted permissions apply only to the peers they intend.
For the broader network, the disclosures close out the two-week window Bitcoin Core announced in late October, when it first signalled that three more fixed bugs from version 30.0 would be described in public.