TL;DR: Bitcoin Core disclosed three security flaws this week, all already patched, the worst of which could stop mining nodes from building valid blocks after a chain reorganization. None of it affected funds directly, but one bug quietly exposed thousands of nodes running Tor to denial-of-service risk they didn’t know they’d signed up for.
Software this widely relied on rarely gets to have a quiet month, and Bitcoin Core just proved it again.On Tuesday, the project published advisories for three separate vulnerabilities, all fixed back in October 2025 and only now made public, which is standard practice for giving node operators time to upgrade before attackers know exactly what to look for.
The headline bug, tracked as CVE-2025-62861 and rated high severity, lived in how Bitcoin Core’s mempool handles transactions that get kicked back in after a chain reorg. A set of rules called TRUC sibling eviction, designed to keep certain linked transactions from clogging the mempool, kept applying even to transactions that had just been reorganized back in. The result was a transaction getting evicted without its dependent transactions going with it, leaving the mempool in a state it was never supposed to reach. For a mining node caught in that state, the practical effect was simple and annoying: it couldn’t build a valid block template until someone restarted it. Niklas Goegge reported the flaw back in September 2025. It affected Bitcoin Core versions 28.0 through 28.2 and 29.0 through 29.1.
The second bug, CVE-2025-62859, is the kind of thing that sounds minor until you picture it running against your own node for ten minutes straight. A malicious peer could exploit witness malleation in compact blocks to delay block processing, and could keep doing it indefinitely against a node running in blocksonly mode, or one where the attacker happened to control all three of its high-bandwidth peer slots. Eugene Siegel flagged this one back in April 2025, which makes it the oldest of the three reports by several months.
The third, CVE-2025-62860, is more of a quiet configuration trap than a flaw in the strict sense. Nodes running the optional, non-default whitelist setting could end up granting trusted permissions to incoming Tor connections if the Tor proxy’s IP address happened to fall inside the configured whitelist range. That sounds narrow, except Bitcoin Core’s own advisory noted that thousands of reachable mainnet nodes were doing exactly this. Whitelisting strips away certain denial-of-service protections and some privacy safeguards, which means a meaningful slice of the Tor-connected network had unknowingly loosened its own defenses.
Patches for all three shipped quietly in Bitcoin Core 30.0 on October 10, 2025, with a backport to 29.2 following four days later. The last vulnerable version line reached its end of life on October 27, so if you’re running something current, you’re already covered. If you’re not sure, that’s the actual news here, not the technical mechanism.
None of the three advisories describe lost funds or a successful real-world exploit. That’s worth sitting with for a second, because it’s also the least reassuring part of the story. Bitcoin’s mempool and peer-to-peer layer are exactly the kind of plumbing nobody notices until it breaks, and three separate paths to breaking it, discovered independently across a few months, is a reminder that the software underneath a trillion-dollar asset is still just software, written and reviewed by people who occasionally miss an edge case involving chain reorgs.
It also lands in a year when crypto infrastructure security has had a brutal run. We’ve tracked the fallout from the Web3Auth and Keplr wallet breach and the more recent domain hijacking that hit Across Protocol, and both of those involved attackers going after the layer just outside the blockchain itself rather than the chain’s core consensus code. Bitcoin Core bugs are a different animal, closer to the foundation than the paint, which is exactly why responsible disclosure and a full year of patch lead time matter more here than almost anywhere else in the stack.
For ordinary holders, the actual action item is boring: if you run your own node, confirm you’re on 30.x or the 29.2 backport. If you don’t run a node and just hold coins through an exchange or wallet, this particular round of bugs was never really about you, though it’s a decent reminder that the infrastructure under your holdings gets probed constantly, by researchers and attackers alike, and you mostly never hear about the near-misses.
The delay between discovery and disclosure is worth explaining rather than treating as suspicious, because it trips people up every time a story like this runs. Responsible disclosure in open source security means fixing the bug quietly first, giving the overwhelming majority of node operators time to upgrade through normal release channels, and only publishing the technical details once enough of the network has likely patched that an attacker reading the advisory can’t immediately weaponize it against stragglers. A year between report and disclosure sounds slow if you’re used to how commercial software handles security bulletins, but it’s roughly standard for Bitcoin Core, where a botched disclosure could theoretically be used to attack nodes that haven’t upgraded yet.
What’s genuinely unusual here is getting three unrelated bugs disclosed in the same batch, reported by two different researchers working independently, covering three different subsystems: mempool logic, compact block relay, and Tor peer permissions. That’s not evidence of some common root cause. It’s more a reminder of how much surface area exists in software that has to stay compatible with over a decade of prior versions while still handling constant hostile traffic from a fully public, adversarial peer-to-peer network. Every one of these three bugs required someone to think adversarially about an edge case most developers would never consider on a normal day of writing features.
The bottom line
Bottom Line: No funds were lost and the fixes have been live for over a year, but a high-severity bug that can stall mining nodes after a reorg is not a rounding error. If you run a node and haven’t checked your version number in a while, now’s a reasonable time to do it.
The Teck Hustlers Editorial Team covers technology, business, finance and gaming news for readers who want the story behind the headline. Every article is researched, written and edited by our in-house team, checked against company announcements, filings and reputable reporting, and updated when new facts emerge. We focus on what each development means for founders, professionals, investors and everyday users. Have a tip or a correction? Reach us through our contact page.
