Monero’s latest security reviews have identified two potential weaknesses in proposed and recently merged code changes, raising questions about how the privacy-focused cryptocurrency protects transaction metadata and verifies payment proofs. The findings concern a possible browser-to-local-node attack involving DNS rebinding and a separate flaw in incoming transaction proofs that could allow a malicious miner or remote node to expose information about a wallet’s transactions.
The findings were published on October 28 and 29, 2026, by the independent GitHub review project xmrack/monero-review. The reviewers classified the RPC findings as three low-severity issues and the transaction-proof finding as medium severity. Neither review reported a confirmed, actively exploited attack, and the transaction-proof assessment was based on source-code inspection rather than experimental reproduction.
The distinction matters. These reports do not establish that Monero’s core privacy mechanisms have been broken across the network. Instead, they identify ways application-layer behavior could undermine privacy protections under specific conditions, even when the underlying cryptographic design remains intact.
Monero RPC restrictions leave a potential DNS-rebinding gap
The October 29 review examined Monero’s pull request #11196, titled “epee: reject HTTP requests from disallowed origins.” The proposed change seeks to prevent websites from sending unauthorized requests to a locally running Monero daemon, known as monerod, by enforcing HTTP-origin restrictions and requiring POST requests for selected RPC endpoints.
The pull request remained open on October 29. Its stated objective addresses a meaningful security problem: browser security policies do not necessarily prevent a local service from processing a request simply because the requesting website cannot read the response. Cross-origin requests can sometimes reach a service even when cross-origin response access is restricted.
The review, documented in xmrack’s October 29 assessment, identified a remaining weakness in the proposed origin gate. The HTTP handler checks the Origin header and, when that header is absent, can rely on the browser’s Sec-Fetch-Site metadata. However, the reviewers found that it does not validate the HTTP Host header.
That omission could leave a route for DNS rebinding. In a typical scenario, an attacker-controlled website initially resolves to an external server and subsequently changes its DNS response to point to the victim’s loopback address, such as 127.0.0.1. If the browser completes the rebinding sequence and treats the request as same-origin, the malicious page may be able to communicate with a local service that was not intended to accept requests from arbitrary websites.
The review says a qualifying request could reach certain GET endpoints, including /get_info, /getinfo and /get_net_stats. Depending on the endpoint and configuration, responses could expose node version and uptime information, connection and peer counts, traffic statistics, or a transaction-pool count that includes transactions still in Monero’s stem-relay phase.
That last detail is significant because Monero uses Dandelion++ to make it harder to connect a transaction’s initial broadcast with its originating IP address. During the stem phase, transactions travel through a limited relay path before being distributed more widely. A local information leak does not automatically reveal a transaction’s identity, but timing and changes in the pool count could give a malicious website additional clues about a visitor’s activity. Monero’s privacy design is outlined in the project’s official overview.
The assessment also identified a separate issue involving monero-wallet-rpc. The shared origin restrictions do not consistently impose the proposed POST and JSON-content requirements on wallet RPC methods. Under a narrower set of conditions, including an unauthenticated wallet RPC configuration and an older browser that omits relevant request headers, a malicious page could potentially reach methods that control wallet operations.
These scenarios require particular configurations and browser behavior. The report did not demonstrate that a remote attacker can reach arbitrary Monero nodes over the internet, and it noted that modern browsers may block or interrupt the DNS-rebinding sequence. The three findings were classified as low severity.
Incoming transaction proofs raise a separate privacy concern
A second review, published on October 28, examined pull request #11565, titled “wallet2: bind incoming transaction proofs to recipient outputs.” Unlike the RPC findings, this assessment received a medium-severity classification because it concerns how a wallet establishes that a cryptographic proof corresponds to a particular transaction output.
Monero transaction proofs let users demonstrate that a payment was made to a particular address without disclosing their entire wallet history. The official Wallet RPC documentation describes the related get_tx_proof and check_tx_proof functionality.
The pull request was merged on October 24. Its intended improvement was to ensure that an incoming proof signs a shared secret only when that secret derives an output belonging to the recipient’s address. The subsequent review, xmrack issue #1385, argues that the proposed check does not sufficiently establish that the matching output belongs to the specific transaction being proved.
According to the reviewers, a malicious miner could construct a coinbase transaction containing a copied output key and transaction public key from a different transaction that paid the victim’s wallet. The review argues that the relevant consensus validation does not prevent this particular duplication.
If the wallet generates an incoming transaction proof for the transaction selected by the attacker and shares it with that party, the resulting proof could reveal which output belongs to the wallet and help the recipient decrypt its amount. If the output is change returned to the sender, the information could also help establish that the wallet initiated the original transaction.
The review identifies another conditional route involving a malicious remote node serving a forged pruned version of a legacy version-one transaction. It does not claim that an ordinary remote node can freely forge modern transaction data without detection.
Crucially, the finding depends on an attacker being able to mine a block containing the crafted output or control the relevant remote node, as well as the wallet owner generating and sharing the requested proof. The review was not experimentally reproduced, and its conclusions remain an independent source-code assessment rather than confirmation of a production exploit.
What the findings mean for Monero users and developers
The two reviews expose different weaknesses, but they point to the same broader issue: privacy depends on more than cryptographic algorithms. It also depends on how wallets validate transaction data, how local services handle browser requests and how carefully new safeguards are integrated across shared components.
For users running their own nodes, the RPC findings reinforce the importance of limiting access to local interfaces. A service bound to a loopback address is not automatically immune to browser-mediated attacks. Authentication, restrictive RPC settings, correct origin validation and method-specific request checks can provide additional protection. Users should avoid unnecessarily exposing wallet RPC services and should not assume that an HTTP origin filter alone prevents every unwanted request.
For wallet users, the transaction-proof finding highlights the importance of verifying what a proof actually establishes before sharing it. A proof intended to confirm a payment should not inadvertently reveal additional information about another transaction simply because the verification process accepts an output that matches the wallet’s address.
Neither finding means users should abandon Monero or assume that their funds are compromised. The reported RPC paths require specific local conditions, while the proof issue requires an attacker to arrange the relevant transaction or node behavior and persuade the wallet owner to generate and disclose a proof. The reviews also do not report evidence of widespread exploitation.
Nevertheless, developers should treat these reports as reasons to examine trust boundaries carefully. Origin validation should account for the host being accessed, and security requirements should be applied consistently to every relevant RPC interface. Transaction-proof validation should establish not only that an output belongs to the intended address, but also that it belongs to the transaction for which the proof is being generated.
The next test is whether proposed fixes close the gaps
The immediate priority is the status of pull request #11196. As of October 29, it remained open, and the latest review identified gaps that the proposed restrictions had not fully addressed. The key questions are whether maintainers add host validation, close the remaining GET-based information paths and apply the POST and JSON restrictions consistently to wallet RPC.
The transaction-proof finding requires a different response. Pull request #11565 had already been merged, meaning the reported weakness concerns code that passed through the project’s normal development process. The next step is to establish whether maintainers accept the finding, develop a correction and determine which releases, if any, contain the affected behavior. A merged pull request does not establish that every user is running the affected code, nor does it mean that a subsequent review finding has been resolved.
Investors should be careful not to interpret these reports as evidence of an immediate compromise of Monero’s blockchain or a demonstrated loss of funds. Their significance is more specific: they show how implementation weaknesses can create privacy risks around a system designed to conceal transaction details.
For the Monero development community, the outcome will depend on the quality of the fixes and the rigor of subsequent testing. Reproducing the proposed attacks in controlled environments, verifying the behavior across supported browsers and checking the wallet’s handling of copied outputs would provide stronger evidence than source inspection alone.
Monero’s privacy model remains built on several complementary protections, but those protections cannot compensate for every application-layer mistake. The central question now is whether maintainers can close the identified gaps without disrupting legitimate RPC clients or weakening the usability of transaction proofs. Until the findings are addressed and independently verified, both cases warrant attention as unresolved security questions, not proof that Monero’s core privacy guarantees have failed.
Johan Shamshad is a financial markets writer at Dave Finances covering cryptocurrencies, trading platforms, brokers, fintech, financial regulation, and developments across global markets. He previously worked at Gulf News, adding newsroom experience to his coverage of fast-moving financial and digital-asset markets.
His work focuses on identifying market-moving events, company developments, regulatory changes, product launches, and shifts in trading and financial infrastructure.
Johan contributes news and analysis designed to help readers understand not only what happened, but why a development matters and how it may affect the wider financial landscape. You can reach out to him via his social media accounts:
Linkedin: https://www.linkedin.com/in/johan-shamshad-742851262/
X: https://x.com/Yasmine_FX
Investing: https://www.investing.com/members/contributors/279781574