Bitcoin Core discloses three node-level bugs, all patched a year ago and sat on until the last vulnerable release died

Bitcoin Core published three coordinated vulnerability disclosures on November 10, 2026. None lets an attacker steal coins, forge a signature, or split consensus. All three are availability or policy defects — a node stalled, a node's DoS protections wrongly waived, or a miner unable to build a block — and all three were already fixed in releases that shipped in October 2025, more than a year before the public writeups.

The timing is deliberate. Bitcoin Core withholds vulnerability details until every affected version has reached end of life, so that operators running patched software aren't handed a working exploit against the laggards still on old builds. The last vulnerable branch, 29.x, went end of life on October 27, 2026; the disclosures followed two weeks later. Here is what was actually found.

The three bugs

CVE-2025-62859 — block processing stall via witness malleation (Medium). In affected versions, a node reconstructing a compact block cleared its download state before checking the block for witness malleation. If that check then failed, the node fell back to re-requesting the full block from the same peer via GETDATA, on a 10-minute timeout. Per Bitcoin Core, a malicious peer that announced a compact block to the victim first could exploit this ordering to stall the victim's block processing — and if the attacker controlled all three of the victim's high-bandwidth peers, or the victim ran with -blocksonly, the stall could be repeated indefinitely. Eugene Siegel reported it to the Bitcoin Core security list on April 28, 2025. Gregory Sanders opened the fix (PR #32646) on May 30, 2025; it merged June 30 and was backported to version 29 on September 12. Fixed in 30.0 (October 10, 2025) and 29.2 (October 14, 2025).

CVE-2025-62860 — inbound Tor connections wrongly granted -whitelist permissions (Medium). This is the one with the largest real-world footprint. Inbound Tor peers appear to a node with the IP address of the local Tor daemon, not their own. The -whitelist option lifts DoS limits and privacy-leak mitigations for trusted peers on a configured IP range. The defect: Bitcoin Core would whitelist an inbound Tor connection whenever the Tor proxy's address fell inside the whitelisted range. Because popular vendors bundled Bitcoin Core with a Tor daemon and set -whitelist to match that daemon's address — and because -whitelist was an operational requirement for some client software commonly run alongside Tor — Bitcoin Core says this led to "thousands of reachable mainnet nodes" whitelisting all incoming Tor connections. Nodes left on the default (no -whitelist) were never affected. Martin Zumsande and Antoine Poinsot reported it on September 12, 2025; the fix (PR #33395) merged and was backported on September 17, the same day Poinsot notified Bitcoin Knots maintainer Luke Dashjr, who acknowledged it immediately. Affected software providers were notified on September 19. Fixed in 30.0, 29.2, and 28.3 (October 20, 2025).

CVE-2025-62861 — block template creation halted by TRUC sibling eviction during reorg (High). The most severe of the three, and the narrowest to trigger. Version 3 ("TRUC") transactions carry extra mempool topology limits under BIP 431 — at most one unconfirmed ancestor and one unconfirmed descendant. These are relay-policy rules, not consensus rules, so a valid block can legally contain topologies the mempool would reject. During a chain reorganization, transactions from disconnected blocks are re-added to the mempool with bypass_limits=true, which is supposed to skip anti-DoS and topology policy and restore them faithfully. The bug: the "sibling eviction" branch (introduced in v28.0) wasn't gated on bypass_limits, so TRUC enforcement kept running during re-addition. A reorg could restore a topology that violates TRUC's descendant limit; sibling eviction could then evict a restored transaction while leaving its descendants behind, so the mempool held transactions spending outputs that no longer existed. The practical effect, per Bitcoin Core: a miner on such a node can't build a valid block template until the node is restarted and the mempool reloads cleanly. Niklas Goegge reported it on September 26, 2025; Greg Sanders's fix (PR #33504) merged October 2 and was backported across the 28.x, 29.x, and 30.x branches. Fixed in 30.0, 29.2, and 28.3 (October 17, 2025).

Key facts

• Disclosure date: November 10, 2026, for all three (bitcoincore.org).
• CVE-2025-62859: Medium; affects versions before 29.2 and 30.0; reported by Eugene Siegel on April 28, 2025; fixed in 30.0 (Oct 10, 2025) and 29.2 (Oct 14, 2025) (bitcoincore.org).
• CVE-2025-62860: Medium; affects versions before 28.3, 29.2, and 30.0; reported by Martin Zumsande and Antoine Poinsot on September 12, 2025; "thousands of reachable mainnet nodes" exposed via bundled-Tor -whitelist configs; default nodes unaffected (bitcoincore.org).
• CVE-2025-62861: High; affects 28.0–28.2 and 29.0–29.1; reported by Niklas Goegge on September 26, 2025; fixed in 30.0 (Oct 10, 2025) (bitcoincore.org).
• Last vulnerable branch (29.x) end of life: October 27, 2026 (bitcoincore.org).

The real-world read

A few things worth stating plainly.

First, there is no marketing here and nothing is being sold — these are primary disclosures from the Bitcoin Core project itself, which is why they read as dry mechanics rather than spin. That's the baseline, not a compliment.

Second, the headline-sounding "High severity" bug (CVE-2025-62861) is real but conditional: it requires a chain reorganization to trigger, it hits miners rather than ordinary users, and it's recoverable with a restart. It doesn't risk funds or consensus. The more quietly consequential bug may be the medium-rated Tor whitelist flaw, precisely because of scale — by Bitcoin Core's own account, thousands of live nodes were waiving their DoS and privacy protections for every inbound Tor peer, not through user error but because common vendor bundling made -whitelist the path of least resistance. That is the gap between a bug's rating and its blast radius, and it's worth noting the rating doesn't capture it.

Third, the disclosure model cuts both ways. Holding details until 29.x reached end of life protects upgraders, and the fixes have been public in the source tree since mid-2025 for anyone reading commit history. But it also means the window of exposure was long: the Tor issue was patched in October 2025, yet anyone who never upgraded has been running it in the open for over a year, and only now gets told why it mattered. The disclosures don't say how many nodes remained unpatched as of November 2026 — that number isn't given, and we won't guess it.

Finally, what's conspicuously absent: any evidence that any of these was exploited in the wild. The writeups describe mechanics and attacker preconditions, not incidents. Treat "could" as "could," not "did."

Opinion, and whose

The severity ratings — two Medium, one High — are Bitcoin Core's own classifications, not independent assessments. No forecasts, price implications, or third-party takes appear in these disclosures, and we're not manufacturing any. The only judgment call on offer is the project's, and it's an availability-and-policy judgment, not a funds-at-risk one.

Sources

• Bitcoin Core, CVE-2025-62859 disclosure (bitcoincore.org, Nov 10, 2026) — primary: full mechanics, severity, attribution to Eugene Siegel, and fix/release timeline.
• Bitcoin Core, CVE-2025-62860 disclosure (bitcoincore.org, Nov 10, 2026) — primary: Tor -whitelist mechanics, the "thousands of reachable mainnet nodes" figure, attribution to Martin Zumsande and Antoine Poinsot, and notification timeline including Bitcoin Knots.
• Bitcoin Core, CVE-2025-62861 disclosure (bitcoincore.org, Nov 10, 2026) — primary: TRUC/BIP 431 reorg mechanics, High severity, attribution to Niklas Goegge, and the cross-branch backport timeline.

All three are official project disclosures; none is sponsored or promotional.

This is news coverage of security disclosures, not security or financial advice. If you run a node, check your version against the affected ranges above and consult the official releases.