Two fresh security reviews of Monero code have identified separate low-severity weaknesses in the network’s node software, including a pre-existing path that could gradually consume memory on IPv6-enabled nodes and a proposed synchronization change that could make monerod crash under an unusual rollback-and-resync sequence.
Neither finding has been linked to active exploitation. They also have very different exposure profiles: the memory-growth issue involves behavior already present in Monero’s code, while the divide-by-zero finding affects an open pull request that has not been merged into Monero.
The first review, published at 02:30 UTC on September 30, examined a proposed change designed specifically to limit several maps used for tracking misbehaving hosts. The patch successfully caps three of those structures at 1,000 entries, but the reviewer found that the final ban map fed by those structures, m_blocked_hosts, remains uncapped.
That creates a slow resource-exhaustion path in which remote peers can intentionally accumulate enough failure scores to get their addresses banned. Each newly banned address creates another entry that can remain in memory even after the ban itself expires.
The Patch Caps Failure Tracking but Leaves the Ban Map Unbounded
The affected pull request, Monero PR #11430, is titled “p2p, rpc: bound and prune host-failure-tracking maps.” It limits two P2P failure maps and one RPC-related map, pruning stale entries and evicting old ones after they reach 1,000 records.
The September 30 security review, however, found that those scores ultimately feed into m_blocked_hosts, which has no equivalent maximum size.
According to the review, a malicious peer can deliberately trigger protocol failures until its address crosses Monero’s banning threshold. The reviewer estimates that creating one persistent ban-map entry costs the attacker roughly 11 inbound connections while consuming approximately 100 bytes of node memory.
That makes the attack slow rather than immediately disruptive. The more interesting problem is what happens after the ban expires.
Monero does not periodically sweep every expired entry from m_blocked_hosts. An expired host is removed when that same host is checked again, while operators can also remove bans manually. An attacker that continuously moves to fresh addresses can therefore leave old records behind.
The review labels the issue LOW severity and explicitly says it was not introduced by PR #11430. A check of Monero’s latest recommended v0.18.5.1 release also shows the underlying ban map accepting new host entries without a size cap.
IPv6 Is What Turns a Slow Leak Into a Potentially Unbounded One
There is an important practical limitation.
Monero disables P2P IPv6 by default. Operators must explicitly enable it with --p2p-use-ipv6.
Without IPv6, the attacker’s ability to grow the map eventually runs into the cost and scarcity of obtaining large numbers of distinct IPv4 addresses. The review also notes that inbound Tor and I2P peers do not provide the same blockable-address path.
An operator who enables IPv6 changes the economics because an attacker controlling a sufficiently large IPv6 range has a vastly larger supply of addresses to rotate through.
Even then, this is not a fast “send one packet and crash Monero” vulnerability. The reviewer did not benchmark the attack against a running node and explicitly says the connection rate and memory figures are estimates derived from code analysis.
That distinction is important. Recent code-level cryptocurrency security disclosures have similarly shown why identifying a reachable software flaw is different from establishing how easily it can be exploited against real infrastructure.
A Second Review Found a Potential SIGFPE During Resynchronization
A separate Monero review published roughly an hour earlier identified another LOW-severity issue in PR #11436, which changes how the daemon calculates synchronization progress.
The proposal is intended to store the starting time and blockchain height once for a synchronization cycle rather than recalculating them on every call.
The reviewer found a problem: the new values appear to be initialized once but never reset when another synchronization cycle begins.
That matters if a node’s blockchain height subsequently moves below the stored starting height.
The review identifies several situations that could produce that condition, including an operator using pop_blocks, a checkpoint rollback or a reorganization onto a shorter chain carrying greater cumulative work.
If the node later synchronizes with peers whose advertised target height exactly equals the old stored starting height, the calculation for total_blocks_to_sync becomes zero.
A later progress calculation then performs an integer division using that zero value. According to the code review, the result would be SIGFPE, terminating monerod.
Several conditions have to align. The blockchain must first drop below the old start height, the relevant synchronizing peers must advertise exactly that height, blocks must subsequently be added, and more than two minutes must have elapsed since the previous synchronization estimate.
More importantly, the reviewer did not compile or run the code to reproduce the crash. The finding is based on static reasoning through the code path.
The Resync Finding Is Not a Vulnerability in the Current Monero Release
This distinction is especially important for users and investors.
PR #11436 remains open and unmerged. The review describes the dangerous divide-by-zero path as newly reachable because of the proposed synchronization change.
That means this is currently a review finding against code being considered for Monero, not evidence that released Monero nodes can be remotely crashed through this exact sequence.
In that sense, the review process is doing what security review is supposed to do: finding a difficult edge case before it enters production.
The memory-growth issue deserves somewhat more immediate attention because its underlying uncapped ban structure is pre-existing. But even there, the review’s own conditions sharply narrow the practical exposure.
Why a Rollback Crash Path Still Deserves Attention
The divide-by-zero scenario sounds extraordinarily specific until the circumstances under which it matters are considered.
Blockchains do occasionally need unusual recovery procedures.
Zano recently rolled back roughly a month of blockchain history after a Gateway Address vulnerability allowed unauthorized assets into circulation. MultiversX separately considered targeted state recovery after a VM-level security incident created invalid state changes.
Those incidents have no technical connection to Monero’s current findings. They illustrate why rollback and resynchronization code is nevertheless important.
The worst time for node software to encounter an obscure synchronization crash is during a network emergency when operators are already reverting state, changing checkpoints or attempting to bring infrastructure back onto an agreed chain.
A bug can therefore be LOW severity under normal conditions while becoming operationally irritating during exactly the type of exceptional event in which reliability matters most.
The Memory Attack Looks More Like Attrition Than a Conventional DoS
The first finding has a different risk profile.
Traditional denial-of-service attacks tend to seek an immediate payoff: send enough traffic, consume enough CPU or trigger a crash.
The m_blocked_hosts issue is closer to attrition.
Every individual entry is cheap. The attacker also has to expend repeated connections to create it. That is why the review rates the problem LOW.
But the asymmetry comes from persistence. The attacker’s connection is temporary while the resulting data can remain resident long after the ban’s expiration unless that host returns and triggers cleanup.
Over a sufficiently long period, that changes the resource-exhaustion equation for publicly exposed IPv6 nodes.
The proposed fix is straightforward in concept: cap m_blocked_hosts, sweep expired entries when the cap is reached and evict an appropriate existing entry if necessary. The reviewer also raises a broader design question over whether IPv6 bans should apply to an entire /64 rather than individual addresses, which would dramatically reduce an attacker’s effective address supply.
There Is No Evidence XMR Funds or Monero Privacy Are at Risk
Neither review describes a way to steal XMR, forge transactions, reveal private transaction information or break Monero’s consensus rules.
The first issue concerns node memory consumption. The second concerns daemon availability during an unusual resynchronization state, and the affected change has not been merged.
That makes dramatic descriptions such as a “Monero exploit” misleading at this stage.
The more useful takeaway is narrower: a patch intended to place limits on hostile-host tracking appears to stop one data structure too early, while a separate attempt to improve synchronization reporting introduces an edge case that could turn a harmless log calculation into a process-ending fault.
Both fixes also appear relatively contained compared with the failures they are designed to prevent.
For Monero operators, the item worth watching most closely is PR #11430 and whether maintainers extend its resource limits to the downstream ban map. Operators who do not enable IPv6 avoid the review’s effectively unlimited address-supply scenario by default.
For PR #11436, the more reassuring detail is that the problem has been identified while the code is still under review. Adding a zero guard and resetting the stored synchronization start point when a new sync begins would address the failure path described by the reviewer before it reaches a release.
These are not catastrophic findings. But they are a useful example of why mature blockchain infrastructure is often tested at its edges: not only in cryptography or consensus, but in ban lists, bookkeeping variables and log calculations that can become surprisingly important when a node is subjected to hostile traffic or an abnormal chain state.
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.