A new security review of Monero’s proposed I2P SAM implementation has identified two medium-severity privacy and key-handling issues, including a flaw that could allow every I2P peer contacted by a node to learn the node’s long-lived published identity.
The findings were published on September 29 in an I2P security review of Monero pull request #10523, which adds native support for I2P’s Simple Anonymous Messaging, or SAM, protocol to monerod.
The distinction is important: PR #10523 remains open and unmerged. The findings therefore concern proposed Monero code under review, not a vulnerability automatically affecting users running the current stable Monero release.
The review, generated through xmrack’s deep-scan security-review workflow, examined 13 changed files at commit e47ee983bab5 and reported two Medium findings. No wallet private keys, Monero spend keys or user IP addresses are reported to be exposed, and there is no indication that either issue has been exploited in the wild.
The More Serious Privacy Issue Links Transient Outbound Traffic to a Persistent Identity
The second finding goes directly to the privacy model the new I2P implementation is designed to improve.
The proposed architecture creates two separate I2P identities. A persistent SAM session accepts inbound connections using a stable published address, while outbound connections are supposed to use a transient destination. In theory, that separation prevents peers contacted by the node from linking outbound activity to the long-lived address used for inbound connections.
The review says the implementation currently breaks that separation during Monero’s routine timed-sync process.
When an outbound peer sends a timed-sync command, the node reportedly includes its persistent published I2P address in the response even though the connection itself originated from the transient outbound session. As a result, the remote peer receives the permanent b32 address that the node was trying to keep separate from its outbound activity.
The finding is particularly notable because the documentation included with the proposed feature says the two-session design keeps outgoing streams from being linkable to the node’s published address.
According to the review, any I2P peer the node chooses to dial could observe the address without performing unusual or malicious protocol behavior.
The exposure does not reveal the operator’s IP address or automatically identify the person running the node. What it does create is a persistent network-level identifier that can potentially be associated with repeated outbound activity across sessions and restarts.
A Second Finding Concerns How the I2P Destination Key Is Written to Disk
The review also found a separate problem involving the private key associated with the node’s persistent I2P destination.
When the key is first generated, the code reportedly creates its file using standard inherited or default permissions and only tightens those permissions afterward.
On POSIX systems, that creates a narrow race condition. Another local user who manages to open the file during the short interval before its permissions are restricted could theoretically retain access to the file descriptor and later read the key after it is written.
On Windows, the concern may be broader because the review says the permission-changing function used in the implementation does not replace inherited access-control lists in the same way a dedicated private-file creation routine would.
An attacker obtaining that key would not gain access to a Monero wallet. Instead, the attacker could impersonate the node’s persistent I2P destination and potentially receive inbound connections intended for it.
The issue requires local access to the machine running the node and, on POSIX systems, a successful timing race during initial key generation. That makes the attack model narrower than the outbound identity leak, which can reportedly be observed by ordinary remote peers.
The Findings Do Not Affect Every Current Monero Node
The timing of the review matters almost as much as the findings themselves.
The new SAM integration has not been merged into Monero’s master branch. Monero’s current CLI release is still version 0.18.5.1, while the latest GUI release is 0.18.5.2.
Users running those standard releases should therefore not interpret the September 29 review as evidence that all Monero nodes are currently leaking persistent I2P identities.
The proposed SAM integration is an attempt to improve Monero’s existing I2P support, which currently relies more heavily on proxy-based configurations. The project was designed to make I2P easier to configure inside monerod and reduce some of the metadata and operational problems associated with SOCKS-based setups.
That makes the discovery useful from a security-development perspective: the problems have surfaced while the functionality is still moving through code review rather than after broad deployment.
The Identity Leak Matters Because Metadata Is the Product Monero Is Trying to Protect
This is where the story becomes more important than the Medium rating might suggest.
A conventional software bug can be serious because it steals money, crashes a system or allows code execution. Privacy software has another failure mode: the encryption can remain completely intact while metadata quietly undermines the protection users thought they were receiving.
The I2P issue is a good example.
The transient outbound destination appears to work. The persistent inbound destination appears to work. Traffic still travels through I2P. No wallet key has to leak. Yet one routine protocol message can reportedly reconnect those two identities.
That is enough to weaken the point of separating them in the first place.
For an adversarial peer, a stable b32 address becomes a label. It does not directly reveal a real-world identity, but it can make activity from what should have been transient outbound sessions linkable to one persistent network identity over time.
That is especially relevant for Monero because users choose the network specifically for privacy. A metadata flaw that might be treated as secondary in ordinary software can be central in a system whose main value proposition is unlinkability.
Catching the Bug Before Release Is the Best-Case Version of a Security Story
Crypto investors are used to reading about vulnerabilities after the damage has already happened.
Recent incidents have included a USDC bridge exploit that forced a payments platform to halt operations, a vault accounting vulnerability capable of creating incorrect withdrawal accounting, and a hard-fork recovery after a virtual-machine exploit.
The Monero case is fundamentally different. There is no disclosed theft, emergency shutdown or compromised blockchain state. The problematic behavior has been identified while the implementation is still being reviewed.
That is what open-source security review is supposed to look like.
It also means investors should avoid treating every security finding as equivalent. A medium-severity issue caught before merge carries a very different risk profile from an actively exploited vulnerability affecting production funds.
The Hard Part Now Is Preserving the Intended Privacy Model During the Fix
The recommended fix for the outbound identity problem sounds straightforward: do not advertise the persistent address when outbound streams are using a different SAM destination.
But privacy engineering tends to become difficult at exactly these boundaries.
The node still needs its persistent address for inbound connectivity and internal self-connection checks. Developers therefore cannot simply remove the address everywhere. They need to ensure the software knows when publishing that identity is necessary and when doing so destroys the privacy properties of the transient session.
The key-file problem has a similarly clear conceptual fix: create the file with private permissions from the beginning rather than creating it broadly and restricting it later.
The bigger question is what happens after patches are proposed. Because PR #10523 changes networking behavior across thousands of lines of code, the fixes will need additional testing to ensure they do not introduce new connection, synchronization or routing problems.
For Monero, the encouraging part is that the issue was found before the feature became standard infrastructure.
The warning is that privacy features cannot be judged only by whether packets travel through an anonymity network. The implementation also has to preserve identity separation at every layer above it.
In this case, the cryptography did not need to fail for the privacy assumption to break. One persistent address inserted into the wrong routine message was potentially enough.
Shane Neagle is a financial markets analyst and digital assets journalist specializing in cryptocurrencies, memecoins, prediction markets, and blockchain-based financial systems. His work focuses on market structure, incentive design, liquidity dynamics, and how speculative behavior emerges across decentralized platforms.
He closely covers emerging crypto narratives, including memecoin ecosystems, on-chain activity, and the role of prediction markets in pricing political, economic, and technological outcomes. His analysis examines how capital flows, trader psychology, and platform design interact to create rapid market cycles across Web3 environments.
Alongside digital assets, Shane follows broader fintech and online trading developments, particularly where traditional financial infrastructure intersects with blockchain technology. His research-driven approach emphasizes understanding why markets behave the way they do, rather than short-term price movements, helping readers navigate fast-evolving crypto and speculative markets with clearer context.