Bitcoin Core Security Vulnerabilities: 3 Patched Bugs That Could Stop Miners

Bitcoin Core disclosed three security flaws on November 10, 2026. All three were already fixed in October 2025, and the worst one could stop a mining node from building valid block templates after a chain reorganization.

No funds were ever at risk. No exploit has been reported, and no proof-of-concept code has been published.

The real story is narrower, and it matters most to people who run nodes on old software.

About 9% of reachable nodes still run versions hit by the high-severity bug. If you run Bitcoin Core 30.0 or newer, these flaws never touched you.

If you run 28.x or early 29.x, this is your cue to upgrade.

What Bitcoin Core disclosed on November 10

Bitcoin Core published three security advisories on its official site on Tuesday, November 10, 2026. Each advisory names a CVE number, the affected versions, and the releases that fixed it.

The project held the details for about 13 months on purpose. Under its disclosure policy, medium and high-severity bugs go public two weeks after the last affected release line reaches end of life.

Version 29.x reached end of life on October 27, 2026, when Bitcoin Core 32.1 shipped, and the advisories followed exactly two weeks later.

That delay protects users. It gives node operators a year to upgrade before attackers learn the details.

The fixes themselves were public code changes in September and October 2025, merged without security labels, which is why the CVE numbers carry a 2025 prefix.

The high-severity bug: a reorg could stop a miner cold

CVE-2025-62861 sits in the mempool, the waiting area where each node holds unconfirmed transactions. It involves TRUC transactions, the version 3 format defined in BIP 431.

TRUC transactions face strict mempool limits: each one may have at most one unconfirmed parent and at most one unconfirmed child.

Version 28.0 added a rule called sibling eviction to police that child limit. When a new transaction would give a TRUC parent a second child, the node drops the existing child if the newcomer pays a higher fee.

The trouble started during chain reorganizations. A reorg happens when a node swaps recent blocks for a competing chain, and it puts the transactions from the dropped blocks back into the mempool.

That re-admission step uses a flag called bypass_limits, which tells the node to skip policy checks and restore the transactions faithfully.

The sibling-eviction code ignored that flag. It kept enforcing the TRUC child limit while confirmed transactions flowed back into the mempool.

A reorg could restore a parent with several children, and eviction would remove one child while keeping the transactions that spend from it.

The mempool then held transactions that spend outputs which no longer exist. Every block template the node assembled failed its own validity check.

The advisory states the result plainly: a node that performed such a reorg cannot produce blocks until it is restarted.

Security researcher Niklas Goegge reported the flaw on September 26, 2025. Developer Greg Sanders opened the fix, PR #33504, three days later.

The fix gates the TRUC checks on bypass_limits, so sibling eviction no longer runs during reorg re-admission, and it merged on October 2, 2025.

What a miner would actually see

The failure is quiet, which makes it worse than a crash. The node stays connected and synced, and it looks healthy.

It simply hands its hashers nothing valid to work on, so the miner earns nothing until someone notices and restarts the node.

A restart reloads the mempool in a consistent state, and the node starts producing templates again. That restart is the only recovery on an affected version.

The permanent fix is an upgrade, and it has been available for over a year.

To see why a stuck node costs real money, read our plain-language guide on how Bitcoin mining works. A miner that cannot build templates cannot compete for the next block, and every missed block is lost revenue.

The two medium-severity bugs

The same disclosure batch carried two Medium-severity flaws. Neither one touches funds, but both could annoy or expose node operators who run the affected settings.

CVE-2025-62859: a peer could stall block processing for 10 minutes

Compact blocks are a bandwidth-saving format that peers use to announce new blocks. A malicious peer could announce a compact block with altered witness data, which made the victim node fall back to requesting the full block from the same peer.

That fallback carries a 10-minute timeout, so one bad peer could stall block processing for up to 10 minutes at a time.

Eugene Siegel reported the flaw in April 2025. The fix, PR #32646, merged in June 2025, and it shipped in Bitcoin Core 30.0 and 29.2.

Note the gap: the final 28.x releases never received this fix, so a node on 28.3 still carries the compact-block stall even though it has the other two fixes.

A 10-minute stall does not lose coins, but it delays confirmation. If you want to see what a delayed confirmation looks like from the user side, our guide on how to check if your Bitcoin transaction is confirmed shows the checks that matter while you wait.

CVE-2025-62860: Tor connections got trusted-peer powers

Bitcoin Core offers a -whitelist setting that lifts denial-of-service limits and privacy protections for trusted peers. The setting is optional and off by default.

On nodes that set it, inbound Tor connections could inherit those trusted permissions when the Tor proxy IP fell inside a configured range.

That matters because Tor connections are anonymous by design. A node operator who whitelisted a range for a trusted peer could unknowingly hand the same powers to strangers arriving over Tor.

Bitcoin Core said thousands of reachable mainnet nodes ran the vulnerable configuration.

Martin Zumsande and Antoine Poinsot reported the flaw in September 2025. The fix shipped in versions 28.3, 29.2 and 30.0.

If you run a node over Tor, check your whitelist settings as part of the upgrade, and our guide on how to run a Bitcoin node at home covers the safer setup choices.

Which versions are safe, and which are not

The three advisories fix at different points, so one version number does not tell the whole story. This table puts all three flaws side by side, and no other outlet has published it in this form.

The table shows the trap clearly. A node on 28.3 escapes the High bug and the Tor bug, but it still carries the compact-block stall.

Only 29.2 and newer close all three. Versions 28.x and 29.x no longer receive fixes at all, so staying on them means living with whatever the next disclosure reveals.

How many nodes still run the old versions

Old versions are still in use across the network. A Bitnodes snapshot taken at 07:07 UTC on November 11 counted 20,342 reachable nodes.

Of those, 1,885, about 9%, identified themselves as Bitcoin Core versions hit by the High bug. Counting all three flaws together, 3,879 nodes, about 19%, reported a version older than at least one of the fixes.

A second, independent crawl agrees. The btcnodes.io snapshot at 13:02 UTC on November 11, at block 975,433, counted 18,165 reachable Core nodes.

It found 1,886 nodes in the range hit by the High bug, nearly the same count as Bitnodes, and 3,950 nodes, about 22%, older than version 29.2.

Two crawls, taken six hours apart, land on almost the same number of exposed nodes. That agreement makes the estimate far stronger than a single snapshot.

Both counts cover only reachable nodes that announce a version, and they exclude about 2,060 Bitcoin Knots nodes.

The counts also cannot show how many of those machines actually mine, or how many use the Tor whitelist setting. The exposure is real, but its practical size depends on what each old node does.

How to check your version and upgrade

Checking takes less than a minute. Run bitcoind -version in your terminal, or open the debug console and run getnetworkinfo to see the version your node reports to peers.

If the number falls in 28.0 to 28.2 or 29.0 to 29.1, upgrade now. If you run 28.3, upgrade anyway, because the compact-block stall still applies to you.

The current release is Bitcoin Core 32.1, and the supported lines also include 30.4 and 31.2.

Download the new release only from bitcoincore.org, and verify the signatures before you install it. Stop the old node, install the new version, and start it again.

The restart also clears any stuck mempool state from a past reorg.

After the upgrade, run bitcoind -version again and confirm the new number. If you set up your node a while ago and want a refresher, the setup guide linked earlier in this article walks through the current best practices.

What this does not mean

Three disclosed bugs sound alarming, but the limits matter. None of the three allowed theft, unauthorized coin creation, or a consensus failure.

None of them affects people who only hold bitcoin in a wallet, and none affects users of BTCPay Server or other software that runs on a patched node.

The disclosure also says nothing about Bitcoin itself being broken. These are bugs in one software implementation, found by researchers, fixed quietly, and disclosed after the vulnerable versions stopped receiving support.

That is the system working as designed.

For miners, the stakes are narrower but real. A stalled node earns nothing while it sits broken, and mining margins in 2026 leave little room for idle machines.

For everyone else, the lesson is simpler: run supported software, and check the version once in a while.

Why the disclosure took 13 months

Bitcoin Core publishes medium and high-severity bugs two weeks after the last affected release reaches end of life. That rule explains the whole timeline.

The fixes shipped in October 2025, the 29.x line reached end of life on October 27, 2026, and the advisories followed on November 10.

The project recently changed its disclosure policy to speed up fixes for easily discovered bugs. That change came too late to affect this batch, which followed the older schedule.

Expect future disclosures to arrive faster when a bug is easy to find.

The 13-month gap is policy, not neglect. The researchers reported responsibly, the developers fixed quickly, and the public learned the details only after the vulnerable versions were already retired.

Node operators who upgraded when 30.0 shipped never had anything to worry about.

Frequently asked questions

Readers asked the same five questions after the disclosure. Here are the short answers.

Are my bitcoins safe after these Bitcoin Core bugs?

Yes. None of the three bugs allowed theft, unauthorized coin creation, or a consensus failure.

They affected node software, not the Bitcoin network or anyone’s wallet balance.

Which Bitcoin Core versions have the bugs?

The High bug, CVE-2025-62861, affects versions 28.0 to 28.2 and 29.0 to 29.1. The Medium bugs reach further: CVE-2025-62859 also affects 28.3, while CVE-2025-62860 affects the same range as the High bug plus earlier versions with the whitelist setting.

Do I need to upgrade if I run Bitcoin Core 30.0 or newer?

No. Versions 30.0 and newer contain fixes for all three flaws.

You were never exposed to the details disclosed on November 10, 2026.

Was any of the three bugs exploited?

No exploitation has been reported for any of the three, and Bitcoin Core has not published proof-of-concept code for them. The advisories do not say whether the bugs were exploited, and no incident has surfaced.

Why did Bitcoin Core wait more than a year to disclose them?

Under its disclosure policy, medium and high-severity bugs go public two weeks after the last affected release line reaches end of life. The 29.x line reached end of life on October 27, 2026, so the advisories followed on November 10, 2026.

The bottom line

Bitcoin Core fixed three bugs in October 2025 and told the world in November 2026. The worst one could silently stop a mining node from building blocks, and about 9% of reachable nodes still run the affected versions.

If you run a node, check your version today. If it reads 28.x or 29.0 to 29.1, upgrade to a supported release such as 32.1.

It takes a few minutes, and it closes all three flaws at once. For a look at the wider picture, see our guide on how Bitcoin miners are taxed, since miners who upgrade also protect the income the tax rules apply to.