Bitcoin Core developers have officially disclosed three security flaws that could have allowed bad actors to freeze block creation for mining pools and stall transaction processing on unpatched computers across the network.
By Elena Kowalski | November 11, 2026
What Happened
On November 10, 2026, open-source maintainers of Bitcoin Core published coordinated security advisories detailing three separate software vulnerabilities. The batch includes one high-severity flaw and two medium-severity issues affecting older releases of the primary software client that powers the Bitcoin network. The public release followed the project’s strict disclosure rules, which keep technical vulnerability details confidential until vulnerable software branches complete their official lifecycle.
For everyday investors checking their balances, the primary takeaway is reassuring: zero user funds were stolen, no private keys were leaked, and the exploits resulted in 0 USD in financial losses. The underlying code bugs were resolved by developers over a year ago in October 2025. Because the older version 29.x release series officially reached its end-of-life milestone on October 27, 2026, maintainers were finally cleared to reveal the mechanics to ensure node runners upgrade their infrastructure.
With Bitcoin trading at 74,418 USD against a cautious broader market and the Crypto Fear & Greed Index registering 29 in Fear, headline security warnings can easily generate unnecessary anxiety. However, this disclosure is a scheduled maintenance audit rather than an ongoing cyberattack. It shows how the network’s decentralized security model quietly neutralizes software bugs behind closed doors before bad actors discover how to abuse them.
- Disclosure date — Coordinated advisories were published on November 10, 2026, following the end-of-support milestone on October 27, 2026.
- Patches deployed early — All three vulnerabilities were fixed in software updates released back in October 2025.
- Financial impact — No wallets were compromised and user losses sit at exactly 0 USD.
- Impacted software releases — Installations operating on unsupported versions 28.0 to 28.2 and 29.0 to 29.1 must upgrade to maintain stability.
How the Attack Worked
To understand the mechanics of the most critical bug, designated CVE-2025-62861, picture a busy restaurant kitchen organizing pending orders on a ticket rail. In Bitcoin, the software maintains a waiting room for unconfirmed transfers called the mempool. When miners assemble transactions into a block, they arrange them in strict sequences so that the funding transfer, or parent, confirms before the spending transfer, or child.
Discovered by security researcher Niklas Goegge in September 2025, this high-severity flaw struck during a blockchain reorganization. A reorganization happens when two miners find competing blocks at nearly identical times, prompting the network to switch to the longer chain and return displaced transactions back to the mempool waiting room. Under specific conditions involving version 3 transactions, Bitcoin Core’s “sibling-eviction” routine accidentally discarded a parent transaction while retaining its dependent child. Because the recipe was missing its primary ingredient, the miner’s block template engine failed validation checks, causing the mining node to freeze and stop producing valid blocks until manually rebooted by its operator.
The second vulnerability, cataloged as CVE-2025-62859 and identified by researcher Eugene Siegel in April 2025, targeted the network’s compact block relay. Compact blocks act like a digital packing slip, letting computers transmit block announcements without resending transaction data they already store. A malicious peer could alter the digital signature data, known as witness data, inside an announcement. When the recipient node detected the mismatch, it purged its download state and suffered a mandatory 10-minute timeout delay before requesting the block again. In specialized configurations like -blocksonly mode, an attacker controlling peer slots could repeatedly stall block delivery.
The third issue, labeled CVE-2025-62860 and uncovered in September 2025, was a network configuration flaw affecting the Tor anonymity network. When a Bitcoin node receives connections through Tor, it identifies the connection using the local Tor proxy address rather than the remote peer’s true IP. Node operators who applied custom -whitelist rules covering their local proxy inadvertently granted trusted status to all incoming anonymous Tor traffic, bypassing standard denial-of-service throttling limits.
I checked the public release repositories and developer logs: the patches were indeed merged into the codebase in October 2025.
Who Is Affected
The most important consideration for cryptocurrency investors is distinguishing between software infrastructure and user custody. Everyday market participants who keep their coins in mobile phone wallets, hardware devices, or centralized trading venues face zero danger from these vulnerabilities. The bugs reside exclusively within node communication logic and block template creation, meaning an attacker could never forge a digital signature, alter an account balance, or divert user funds.
Instead, operational disruption threatened infrastructure managers running legacy software. Mining pools and industrial mining farms that failed to update past version 28.2 or version 29.1 risked having their block generation routines locked up during chain reorganizations. In a high-stakes industry where mining equipment consumes substantial electrical power, every frozen template represents forfeited transaction fees and missed block subsidies.
Similarly, node operators who intentionally restrict their machines to -blocksonly traffic or employ complex routing setups over Tor faced potential stalling or unwanted traffic spikes. Fortunately, because institutional miners and major node providers maintain active maintenance cycles, the vast majority of hash power had already migrated to secure versions long before this public advisory.
What the Team Is Doing
The handling of these three advisories illustrates the coordinated disclosure strategy that has protected Bitcoin Core for over fifteen years. Rather than publishing vulnerabilities immediately and providing malicious actors with an operational roadmap, maintainers enforce an embargo window. Developers engineer fixes quietly, verify them thoroughly across peer reviews, and package them into routine maintenance releases.
The development team successfully deployed corrective code across versions 28.3, 29.2, and 30.0 in October 2025. To ensure network stability, technical disclosures remained confidential until the entire version 29.x lineage reached its formal end-of-life on October 27, 2026. With that support window closed, developers published comprehensive Common Vulnerabilities and Exposures documentation on November 10, 2026 to uphold transparent open-source standards.
Core developers are actively reminding remaining infrastructure operators to upgrade to version 30.0 or newer editions to completely eliminate potential peer-stalling vectors.
How to Protect Yourself
Navigating network infrastructure updates requires understanding your role in the crypto ecosystem:
- Retail holders and mobile users — No action is required. Your assets, wallet seed phrases, and private keys remain unaffected by node relay vulnerabilities.
- Independent node operators — Verify your node version by checking your client status. If your node runs software older than version 29.2 or version 30.0, download and verify the latest official binary from the official project distribution channels.
- Mining pool administrators — Ensure all block template creation systems have retired outdated version 28.x and version 29.x daemons to prevent template generation deadlocks during chain reorganizations.
- Tor relay managers — Inspect your node configuration files to confirm that local proxy IP addresses are not included in broad -whitelist directives.
- Beware of fake update scams — Scammers frequently exploit security news by circulating phishing links claiming to offer emergency patches; only download software through official cryptographic release signatures.
Elena Kowalski’s take
From where I sit, coordinated vulnerability embargoes reflect the quiet discipline that keeps decentralized networks alive long before attackers spot structural flaws. My gaze turns to node telemetry across release 30 and newer to see whether the final holdout mining pools retire unsupported releases before malicious peers probe those stalling vectors. A single unpatched validator pool dropping offline during an unexpected chain reorganization would quickly prove that relying on voluntary operator upgrades carries real operational risks.
The cryptocurrency market remains highly volatile. This article is for informational purposes only and does not constitute financial advice.
bugs were fixed in october 2025 and we only hear about it now because 29.x hit end of life on oct 27. disclosure process working as intended but still wild how quiet this stayed for a year
thats how coordinated disclosure is supposed to work though. publishing the mechanics earlier wouldve handed a blueprint to anyone still running unpatched nodes
the compact block relay one is the nasty one. a malicious peer tweaks witness data inside an announcement and your node purges its whole download state. no funds at risk but imagine a pool getting frozen mid-block
was on 29.x til last month. 0 usd losses sure but the stall vector on unpatched relays is real. upgrade your nodes folks, this stuff is free to fix
free to fix and half the network still sat on 29.x until end of life. exactly why disclosure waits for branch death, people dont patch until forced
the compact block relay purge is nastier than people admit, a pool frozen mid round is a stall waiting to happen. the patch is one command
one high severity, two medium, zero funds at risk, disclosed a year after the fixes. coordinated disclosure working exactly as designed