Bitcoin Core Vulnerabilities: Three Patched Bugs Disclosed

Bitcoin Core developers disclosed three previously patched Bitcoin Core vulnerabilities on Nov. 10, 2026, including a high-severity flaw that could prevent an affected miner’s node from building new BTC▲$74,416.00 blocks until it was restarted. The mining bug affected versions 28.0–28.2 and 29.0–29.1.

Fixes shipped in October 2025. The newly published advisories explain how the bugs could interrupt mining, delay block processing or weaken protections on Tor-connected nodes, making software versions and configuration the practical concerns for operators.

💡Bitcoin Core's Three Disclosures Cover Mining, Processing and Tor
📎Who Reported the Mining Bug and Released the Fixes?
🧩How TRUC Transaction Handling Could Break Block Templates
⚠️Block-Processing Delays and Tor Permissions Created Separate Risks
🔸Bitcoin Core Versions: Where the Vulnerabilities Were Patched
🔹Why Bitcoin Core Published the Advisories After the Fixes
🔸What Node Operators Should Watch Next
❓FAQ

Bitcoin Core’s Three Disclosures Cover Mining, Processing and Tor

Which Vulnerability Received the High-Severity Rating?

CVE-2025-62861 concerns block-template creation. After a blockchain reorganization, affected software could leave its mempool in an inconsistent state and fail the validity check required to produce a usable template.

That failure could interrupt the work through which a miner earns block rewards. The consequence depended on the miner relying on the affected node: the advisory describes a failure in that node’s ability to assemble blocks.

What Do the Two Medium-Severity Bugs Affect?

CVE-2025-62859 could allow a malicious peer to stall a node’s block processing using manipulated transaction witness data. CVE-2025-62860 concerned inbound Tor connections receiving whitelist permissions that lifted denial-of-service and privacy protections.

The batch therefore spans operational availability and protective controls. According to Decrypt, developers reported no evidence of exploitation. All three vulnerabilities had already received fixes before the public advisories appeared.

Who Reported the Mining Bug and Released the Fixes?

When Did Niklas Goegge Flag the Problem?

Security researcher Niklas Goegge first reported the mining vulnerability on Sept. 26, 2025. Bitcoin Core developers subsequently integrated the repairs into software releases and published the security advisories on Nov. 10, 2026, per U.Today.

The sequence matters for operators reviewing the news: the report, patch releases and public technical disclosure were separate events. The November advisories exposed the details of vulnerabilities addressed in the previous year.

What Role Does Bitcoin Core Play?

Bitcoin Core is the reference software used by the majority of Bitcoin network nodes. Its developers maintain the software, issue patched releases and apply a security-disclosure policy that governs when vulnerability details become public.

The project’s severity framework runs from low to critical. This batch contains one high-severity vulnerability and two medium-severity vulnerabilities, placing the mining interruption above the processing and Tor issues within that framework.

How TRUC Transaction Handling Could Break Block Templates

Why Did Transaction Policy Matter During a Reorganization?

The mining vulnerability involved version 3 transactions, known as TRUC, and restrictions established under BIP-431. These restrictions govern transaction admission and relay through the mempool; valid blocks can contain transaction arrangements outside those policy limits.

A chain reorganization disconnects previously accepted blocks when the network adopts an alternative chain. Transactions from those disconnected blocks then need to return to the mempool so they can be included again.

Bitcoin Core restores them using bypass_limits=true. That setting is intended to bypass the normal mempool limits and transaction-topology restrictions during restoration, preserving the transactions from the disconnected blocks.

How Did Sibling Eviction Leave Transactions Stranded?

Bitcoin Core 28.0 introduced sibling eviction for TRUC transactions. When a new child transaction pays enough under replace-by-fee rules, the software can remove an existing child transaction to accommodate it.

The bug arose because that eviction branch continued to run while transactions were being restored with limits bypassed. As CryptoPotato explains, the process could remove a restored transaction while leaving other transactions that spent its now-unavailable outputs.

The resulting inconsistency reached the block-template validity check. A template assembled from that mempool failed validation, leaving the miner unable to produce blocks through the affected node until restart.

Block-Processing Delays and Tor Permissions Created Separate Risks

How Could CVE-2025-62859 Delay a Node?

The block-processing vulnerability involved a peer announcing a compact block with manipulated witness data. Under the circumstances described in the advisory coverage, an affected node could wait up to 10 minutes before processing the block.

Specific configurations made the attack repeatable indefinitely. That repeatability was the operational concern: a malicious peer could keep imposing the delay on a susceptible node rather than causing only a single interruption.

This flaw targeted the processing of an incoming block. The mining vulnerability reached a different stage of operation, interfering with the affected node’s construction of a new block template after transaction restoration.

Which Tor Connections Received Extra Permissions?

CVE-2025-62860 wrongly granted whitelist permissions to inbound connections over Tor. Those permissions lifted various protections intended to limit denial-of-service and privacy risks.

The exposure depended on the optional whitelist configuration. According to U.Today, thousands of reachable Bitcoin mainnet nodes had been granting such permissions, making configuration review relevant alongside checking the installed release.

For operators using that option, the practical issue was the treatment of incoming connections. Permissions intended to alter how selected peers were handled were being applied to Tor connections incorrectly.

Bitcoin Core Versions: Where the Vulnerabilities Were Patched

Which Releases Contained the Mining Vulnerability?

The affected mining releases were Bitcoin Core 28.0, 28.1 and 28.2, together with 29.0 and 29.1. These version ranges identify the software exposed to the TRUC-related block-template failure.

Operators reviewing older installations can use those ranges to identify the relevant mining-bug exposure. The Tor issue also requires attention to the optional whitelist setting, while the indefinitely repeatable processing stall depended on specific configurations.

Which Releases Delivered the Repairs?

Bitcoin Core 30.0, released on Oct. 10, 2025, and Bitcoin Core 29.2, released on Oct. 14, 2025, included fixes for all three vulnerabilities. Bitcoin Core 28.3 separately contained the mining-vulnerability fix.

These releases mark the documented patch boundaries. Operators are generally urged to run the latest software so their installations receive the project’s security updates.

The distinction between recovery and repair is important for a miner experiencing the template failure. Restarting restored block-template creation after the inconsistent mempool state; installing a patched release addressed the underlying software flaw.

Why Bitcoin Core Published the Advisories After the Fixes

How Did the Embargo Determine Disclosure Timing?

Bitcoin Core’s severity-based policy generally delays disclosure of medium- and high-severity vulnerabilities until at least two weeks after the last affected release reaches end of life. That schedule explains the gap between the October 2025 patches and the November 2026 advisories.

The policy gives operators time to upgrade before detailed vulnerability descriptions become public. For medium- and high-severity issues, the embargo typically lasts about a year after the initial fix.

Critical vulnerabilities receive special handling. That category covers threats such as protocol-level coin theft, unauthorized coin creation and permanent network-wide chain splits; the disclosed batch was classified within the high and medium tiers.

Why Did Antoine Poinsot Argue for Faster Releases?

In an Oct. 22, 2026 message to the Bitcoin Development Mailing List, Bitcoin Core developer Antoine Poinsot explained a separate policy revision for vulnerabilities that are easy to discover or rediscover. He pointed to large language models lowering the effort required to identify certain software flaws and previously concealed fixes.

For those issues, Poinsot argued that an embargo “achieves little but it delays the availability of a fixed release.” The revised approach prioritizes getting patches to maintained software branches quickly.

The policy pull request was submitted on Oct. 16 and merged on Oct. 22. It introduced an “easily discoverable” classification that can include vulnerabilities uncovered through a simple AI prompt.

What Node Operators Should Watch Next

What Does the Revised Policy Mean for Maintained Versions?

For easily discoverable vulnerabilities, developers will backport fixes to every actively maintained major version and publish security advisories alongside the patched releases. This allows operators on maintained branches to receive expedited repairs.

Vulnerabilities outside that classification retain the severity-based disclosure timelines. The project therefore has different publication schedules depending on how it assesses an issue’s discoverability and severity.

The revised approach also changes the testing tradeoff. Poinsot acknowledged that faster security releases could reduce the time available for testing in development branches, while arguing that straightforward, easily verified repairs can justify accelerated delivery.

Which Operational Checks Follow From These Advisories?

For miners, the relevant checks are the release used by the node supplying block templates and whether that release contains the TRUC repair. For Tor operators, the optional whitelist configuration is central to the permissions vulnerability.

The processing advisory adds another configuration-dependent concern: a peer could impose repeated delays on susceptible nodes. Together, the three disclosures make release maintenance and configuration review the immediate priorities for operators responsible for those systems.

FAQ

When Was Bitcoin Core 30.0, Which Included Fixes for All Three Vulnerabilities, Released?

Version 30.0 became available on Oct. 10, 2025. It carried repairs for the mining, block-processing and Tor-permission vulnerabilities later described in the November 2026 advisories.

When Did Bitcoin Core 29.2 Make the Fixes Available to the 29.x Release Line?

The 29.x branch received the three fixes through version 29.2 on Oct. 14, 2025. The earlier 29.0 and 29.1 releases were among those affected by the mining bug.

Which 28.x Release Patched the Mining Vulnerability?

Bitcoin Core 28.3 included the repair for CVE-2025-62861. That addresses the mining flaw identified in versions 28.0–28.2.

Which Optional Configuration Made Tor-Connected Nodes Susceptible to the Whitelist Flaw?

The issue depended on use of the optional whitelist configuration. On affected installations, inbound Tor connections incorrectly received permissions that relaxed denial-of-service and privacy protections.

What Transaction-Chain Limits Does BIP-431 Impose on TRUC Transactions?

BIP-431 limits a TRUC transaction to one unconfirmed ancestor and one unconfirmed descendant. Those mempool-policy limits were central to the sibling-eviction behavior implicated in the mining failure.

How Could an Affected Miner Restore Block-Template Creation After the Mempool Failure?

A restart allowed the affected node to resume creating block templates. A patched release was still needed to address the bug responsible for the inconsistent mempool state.

How Will Easily Discoverable Vulnerabilities Be Disclosed Under the Revised Policy?

Public advisories will accompany the patched releases for vulnerabilities assigned that classification. Developers will also backport those repairs across actively maintained major versions.

This article is for information only and is not financial advice.