Bitcoin Core developers have disclosed three previously patched security flaws, including a Tor-related permissions mistake that affected thousands of reachable nodes and a high-severity bug that could stop an affected mining node from building blocks until restarted.
The immediate takeaway is practical: operators need to know which software and configuration they run. The advisories describe weaknesses in node software, not evidence that Bitcoin’s supply rules failed or that private keys were stolen.
Bitcoin Core Tor bug crossed a trust boundary
The Tor security advisory explains how incoming Tor connections could inherit permissions intended for trusted computers. Tor traffic reached Bitcoin Core through a local service. If an operator’s whitelist included that service’s address, outside connections could receive the same exemptions as trusted local peers.
Those permissions relax some denial-of-service limits and privacy protections. The consequence was a mismatch between the operator’s intended trust boundary and the connections actually receiving that trust.
The developers said the configuration led to “thousands of reachable mainnet nodes whitelisting all incoming Tor connections.” That describes affected deployments identified in the disclosure; it is not a current census of nodes still running vulnerable software.
Nodes that never enabled the non-default whitelist setting were not affected by this issue. The advisory rates it medium severity and identifies fixes in Bitcoin Core 30.0, 29.2 and 28.3, released in October 2025. The detailed public disclosure followed on November 10, 2026.
The three vulnerabilities were patched in October 2025 and publicly disclosed on November 10, 2026. Graphic: BNC. Source: Bitcoin Core advisories. A separate flaw could interrupt mining
The high-severity advisory concerns what happens to pending transactions after a chain reorganisation. A reorganisation occurs when a node switches to a competing valid chain with more accumulated work, and transactions from disconnected blocks may return to its pending pool.
Under particular conditions, affected software could restore dependent transactions inconsistently. A mining node could then assemble a candidate block containing transactions whose required inputs were missing. Its own validity checks would reject that candidate, preventing successful block-template creation until a restart restored a consistent pending pool.
This was a failure in an affected node’s ability to prepare a block, not a mechanism for making the wider network accept an invalid one. That distinction explains both the operational seriousness for a miner and the limit of the disclosure’s implications for ordinary holders.
Bitcoin Core rates the issue high severity. The affected versions were 28.0–28.2 and 29.0–29.1. The disclosure credits Niklas Goegge with finding and responsibly reporting it in September 2025. It does not report an attack exploiting the flaw.
The third advisory concerns delayed block processing
A third advisory describes a separate way a malicious peer could delay an affected node’s processing of new blocks. Its severity is medium, and fixes were released in Bitcoin Core 29.2 and 30.0.
The concern is availability: a computer may be running but failing to keep up with the network promptly. For a business relying on its own node, that can complicate transaction monitoring and the timely interpretation of confirmations even without changing the ownership of any coins.
The advisory identifies conditions under which disruption could be repeated. Operators should follow the developers’ published guidance and use maintained software, rather than assume that a visible connection to peers guarantees the node is processing the latest chain correctly.
Why disclose bugs after fixes have been available for a year?
The timing follows Bitcoin Core’s disclosure policy. For medium- and high-severity issues on the standard timetable, detailed disclosure normally comes two weeks after the last affected release reaches end of life. The November advisories identify October 27 as that milestone.
That approach gives operators time to upgrade before a fuller explanation becomes public. It also creates an important distinction for news readers: newly disclosed does not necessarily mean newly introduced or newly fixed. In this case, the repair dates are in October 2025.
The policy now makes a separate provision for easily discoverable vulnerabilities, including flaws that can be found with minimal effort using an AI model. Such issues can receive a patched release and advisory as soon as possible. The three November 10 disclosures followed the longer timetable.
What Bitcoin users should take from the disclosures
For node operators, the relevant questions are version, configuration and operational dependencies. A package supplied by another vendor may bundle Bitcoin Core with additional software and settings, so checking only the name of the application is insufficient. The Tor issue shows why default assumptions about trusted local connections deserve attention.
For holders using a hosted wallet or exchange, these advisories do not instruct them to move funds to a new address. Their service provider manages the underlying infrastructure. The appropriate distinction is between infrastructure maintenance and a wallet-key compromise; the published flaws concern the former.
The subject is also separate from the longer-term cryptographic risks discussed in BNC’s report on Bitcoin public-key exposure and quantum computing. A software patch addresses a specific implementation weakness. Planning for future quantum capabilities involves a different set of protocol and wallet decisions.
The disclosures reinforce a familiar but consequential point: decentralised money still depends on well-maintained software. Readers can take the bugs seriously without mistaking them for evidence that every Bitcoin node was affected, that funds were stolen, or that the network stopped enforcing valid blocks.