Tor peers could inherit trusted permissions
In its primary advisory on the Tor vulnerability, Bitcoin Core said older versions could apply whitelist permissions to inbound Tor connections when the Tor proxy matched an IP range configured as trusted. Under those circumstances, a node could treat every peer arriving through that proxy as if it were an approved local or private connection.
The issue affected a specific configuration rather than every Bitcoin Core installation. Nodes that did not enable the relevant whitelist setting were not exposed to this behavior. However, Bitcoin Core said the configuration may have been used by thousands of reachable Bitcoin mainnet nodes, making the bug significant despite its limited conditions.
The underlying problem involved how the software identified the apparent source of a connection. Because Tor traffic could appear to arrive from the local Tor service, the connection could match a range intended for trusted computers. An outside user connecting through Tor would then receive the same relaxed treatment as a peer that the operator had deliberately authorized.
The practical consequence was not the direct theft of bitcoin. Instead, outsiders could bypass restrictions that operators believed were protecting their nodes. Those restrictions can affect how nodes handle spam, relay traffic and privacy sensitive information. The incident therefore illustrates a recurring infrastructure risk: a configuration intended to improve privacy can also alter the trust boundaries around a node.
Bitcoin Core rated the Tor issue as medium severity. The project privately warned affected software providers in September 2025, and fixes were included in releases issued the following month. The detailed disclosure was delayed until the older 29.x release series had reached the end of its support window. That timing reflects the project’s effort to give users and downstream software providers time to upgrade before publishing technical details that could make exploitation easier.
Mining reliability was also at risk
A separate vulnerability had a more direct effect on mining operations. Bitcoin Core’s advisory for CVE-2025-62861 describes a high severity mempool inconsistency that could arise after a chain reorganization.
The vulnerability involved a rule introduced in Bitcoin Core 28.0 for transactions using the TRUC policy framework. During a reorganization, one transaction could be removed from the mempool while dependent transactions remained. This left the transaction pool in a state that could prevent the node from producing a valid block template.
For a mining node, the effect could be operationally serious. The node might stop assembling valid blocks until its operator restarted the software. The problem did not change Bitcoin’s consensus rules, and the available information does not indicate that attackers used it to create invalid coins or rewrite the blockchain. Instead, it could have stopped an affected miner from participating normally in block production.
That distinction matters for the broader network. A consensus failure would threaten whether nodes agree on the valid history of transactions. A block template failure is different, but still economically important because it can reduce a miner’s ability to compete for rewards and can interrupt the infrastructure that supports transaction confirmation.
Bitcoin Core said no attacks had been reported against the mining related vulnerability. Even so, the disclosure highlights why mempool behavior deserves security scrutiny. The mempool is not part of the permanent blockchain, but its rules determine which transactions nodes relay, retain and offer to miners. A subtle inconsistency in that temporary layer can create a service outage without breaking the underlying consensus system.
Block processing could be stalled
The third issue concerns the processing of new blocks. In its advisory for CVE-2025-62859, Bitcoin Core said a malicious peer could use witness malleation to make a node stall block processing for 10 minutes.
The disruption could be repeated if an attacker controlled all three of a node’s high bandwidth relay connections. Bitcoin Core also identified exposure for nodes operating with the -blocksonly option. That means the threat was not limited to a single unusual deployment model, although the conditions required for sustained disruption were more demanding than simply opening a connection to a public node.
A repeated stall could delay a node’s view of the chain’s latest state. For ordinary users, that can affect transaction confirmation awareness and the speed at which wallets or services update their records. For businesses and infrastructure providers, repeated delays can create uncertainty around deposits, withdrawals and payment monitoring, even when the blockchain itself continues to operate.
Disclosure policy is changing
The disclosures also arrive as Bitcoin Core is revising how it handles the period between fixing a vulnerability and publishing technical details. The project’s security advisories policy sets disclosure timelines according to severity and now includes an expedited process for flaws that can be rediscovered easily, including through a simple large language model prompt.
That change reflects a new reality for open source projects. Traditional disclosure practices often assume that a vulnerability will remain difficult to find after developers patch it. AI assisted code analysis may shorten that window by allowing researchers, attackers or competing operators to identify the same weakness from public code and a relatively simple request.
For Bitcoin, the policy question is especially important because the software is deployed by a diverse set of operators across jurisdictions. Exchanges, miners, payment companies, privacy users and individual node operators may all follow different upgrade schedules. A delayed advisory can give them time to patch, but it can also leave users unaware of a risk. An immediate disclosure can improve transparency while increasing the chance that unpatched systems are targeted.
The three vulnerabilities do not indicate a failure of Bitcoin’s monetary rules. They do show that network resilience depends on more than consensus. Trust configuration, privacy tools, transaction pool design, peer selection and disclosure timing all shape how reliably the system works in practice. For operators, the immediate lesson is to track supported Bitcoin Core releases and review Tor and whitelist settings rather than assuming that a node’s default privacy architecture also defines a safe trust boundary.
Sarah Thompson is not a person. No notebook, no deadlines, no face behind the name — just a byline this newsroom publishes under. Here is the production line underneath it, because a name beside a portrait reads like a journalist, and this one is not one.
The models. Writing: gpt-5.6-luna. Out on the live web: gpt-5.6-luna and gpt-5.6-terra. Pictures: gpt-image-1. Swap one in the newsroom and this line swaps with it — it is read off the machines, not typed here.
How a story is made
- Research. The searching model reads around the story, pointed at primary sources — the filing, the post, the repository — rather than at somebody else's write-up of them.
- Writing. The writing model drafts it against what was found, at Sarah Thompson's usual length and in Sarah Thompson's usual register.
- The loop. A reviewer reads the draft and sends it back with notes. Then reads it again. A piece can go round several times before it leaves the building.
- Enrichment. A quotation has to appear word for word on the page it is taken from. A chart may only use figures that appear in the source it cites. Whatever fails is dropped, and the reason is kept.
- Fact check. A last pass hunts for claims the article makes and its sources do not.
- A human stop. Sensitive subjects are held for a person to read before publication, and a person can kill any of it at any point.
If that sounds less like a newsroom and more like a factory: quite. It is called Press Factory.
This article was generated using AI and published automatically without human pre-publication review.
Read and checked by admin on 11/12/2026
How this article was made
The article was produced by the Grandmonts Media News Engine using automated research, drafting and verification workflows. No human editor reviewed the article before publication. Grandmonts Media remains responsible for the published content. Errors can be reported at office@grandmonts.cz.