- Bitcoin Core’s 10 November disclosure covered three bugs, not one. CVE-2025-62861 could leave a node unable to assemble a block until it was restarted, and versions 28.0 to 28.2 and 29.0 to 29.1 were affected.
- A second flaw, CVE-2025-62860, meant inbound connections arriving over Tor could inherit whitelist permissions their operator never granted them. CoinDesk puts the number of nodes left in that state in the thousands.
- All three were fixed in October 2025, starting with version 30.0 on 10 October, with backports to 29.2 and 28.3 the following week. Nobody’s coins were at risk in any of them, and the advisory for the bug reports no sign it was ever triggered on the live network.
Headlines containing the words “Bitcoin” and “High severity” usually make people go and check their balances. This one has nothing to do with them. The flaw sat in the software that runs the network’s computers, not in the keys that control anyone’s money, and the worst it could do was stop one of those computers doing part of its job until someone switched it off and on again.
If you hold bitcoin on an exchange, in an app, or on a hardware wallet, there is no action here for you. The handful of UK readers who run their own node have slightly more to think about, because a second bug in the same batch quietly handed privileged access to anyone connecting over Tor. Check which version you are running, and move to a supported one if you are not on it.
What Bitcoin Core actually is
Bitcoin has no head office and no server anyone owns. It runs on thousands of ordinary computers around the world, each one keeping a full copy of the transaction record and checking every new transaction against the rules. Those computers are called nodes.
They all need to be running some piece of software that knows the rules. Bitcoin Core is the version that the overwhelming majority of them run. It is free, open source, and maintained by a loose group of volunteer developers rather than a company, which is why a bug report in it is handled through a mailing list and a public advisory instead of a corporate press office.
Each node keeps a waiting room of transactions that have been broadcast but not yet written into a block. That waiting room is called the mempool. When a miner wants to try for the next block, its software reaches into the mempool and assembles a candidate block, known as a block template. The bug lived in that process.
What went wrong
Occasionally two miners find a block at almost the same moment and the network briefly runs on two competing versions of history. One version wins, the blocks in the losing branch are discarded, and the transactions they contained are tipped back into the mempool to wait their turn again. That event is a reorganisation, or reorg, and it is a normal, expected part of how bitcoin settles.
Separately, Bitcoin Core applies extra rules to a newer class of transaction known as version 3 or TRUC, set out in BIP 431. A TRUC transaction is allowed at most one unconfirmed parent and one unconfirmed child. If a second child turns up and pays a high enough fee, the node’s “sibling eviction” logic, added in version 28.0, throws the first child out.
Those two things did not get on. When transactions were restored to the mempool after a reorg, they were meant to skip the usual policy checks. The sibling eviction branch was never told to skip them, so it kept running, and it could evict a restored transaction while leaving that transaction’s descendants sitting in the mempool with nothing to attach to. The node’s view of its own waiting room no longer made sense, and from that point it could not put together a valid block template at all.
A restart cleared it, because the node rebuilds a consistent mempool on the way up. A miner who hit this would have lost whatever revenue the gap cost before somebody noticed. The advisory does not say whether any miner or pool ever hit it in production, only that the condition was possible.
Why it surfaces now, thirteen months after the fix
The researcher Niklas Goegge reported it to the Bitcoin Core security mailing list on 26 September 2025. A fix was merged on 2 October and went out in version 30.0 on 10 October, followed by backports to 29.2 on 14 October and 28.3 on 17 October. The project credits Goegge with “discovering and responsibly disclosing” the issue.
All three advisories stayed sealed until 10 November 2026, a fortnight after the last vulnerable release line, 29.x, reached end of life. That is the point of an embargo. Publishing the details while thousands of nodes are still running the broken code hands a working recipe to anybody who fancies trying it, so the write-up waits until the people who needed to upgrade have either done so or stopped being supported.
It does make for an odd read. The timeline describes a tidy, fast-moving response that happened over a year ago, and the project has every reason to present it that way, but the speed is in the merge dates rather than in the telling.
The other two bugs in the same batch
CVE-2025-62860 is the one that touched the most machines, and it is the bug CoinDesk led on when it covered the disclosure. Bitcoin Core lets an operator mark certain connections as trusted, a whitelist. Peers on that list skip rate limits, are not disconnected for misbehaving, and can have their transactions relayed when ordinary policy would drop them. The usual reason to turn it on is a wallet or a block explorer running on the same machine.
A node reachable over Tor never sees those peers directly. Tor hands them over through a service running on the same computer, so to the node an inbound Tor connection looks like it came from the machine itself. On nodes configured to extend whitelist permissions locally, that is what happened: anyone who could connect over the hidden service inherited privileges intended for the operator’s own software. CoinDesk puts the number of nodes left in that position in the thousands.
What that actually buys an attacker is narrower than the phrase “trust any stranger” suggests. Whitelist permissions do not touch the consensus rules, so nobody could spend a coin or forge a block with them. They relax the defences that stop a peer flooding a node with junk or getting itself banned for it. It is still a privilege handed to the wrong people, on a lot of machines, across several releases.
The third, CVE-2025-62859, was rated Medium and is the most obscure of the set. It describes a malicious peer stalling block processing on a node by malleating witness data in compact blocks, under certain conditions. Different mechanism, same shape of consequence as the mining bug: a node temporarily unable to do its job, not a path to anyone’s coins. All three were fixed in the same October 2025 releases.
What to watch
Whether any mining pool, exchange or large node operator follows up with an advisory of its own. The Bitcoin Core project can only speak for its own software, and nothing in these disclosures tells you whether anyone downstream saw real disruption last autumn, or whether a Tor peer ever abused the permissions it should not have had.
The version numbers nodes report are public, and crawlers publish the breakdown. Now that the Tor issue is described in the open, the share of reachable nodes still sitting on end-of-life releases is the figure worth a glance. Those machines are not getting a backport.
More generally, this is the second class of bug in a year to arrive via the TRUC rules introduced in version 28.0. New transaction policy interacts with old machinery in ways that are hard to reason about in advance, and reorg handling is where those interactions tend to show up. If a third one lands in the same area, that is a pattern worth noting rather than a one-off. For everyone else, the useful habit is unchanged: stay on a supported version if you run a node, and keep your storage arrangements for bitcoin separate from whatever the software is doing.