Monero v0.18.5.3 and Tor 0.4.9.14 arrive with security and reliability fixes. Restricted RPC clients need a compatibility check.
1. Monero v0.18.5.3 released
October 6, 2026 · Upgrade planning at the briefing date
Affects Monero nodes and RPC consumers.
Monero v0.18.5.3 ships fixes for peer connections, restricted RPC, ZMQ, database handling and logs. It disables get_transaction_pool on restricted RPC. Check any application that uses this method through a restricted public endpoint before upgrading.
- Check downloaded binaries against the official signed hash list. Preserve a consistent database backup and confirm synchronization, wallet connectivity and P2Pool reconnection after restart.
- This was the new Monero release that week. Later editions cover the DNSSEC problem and the subsequent v0.18.5.4 fix.
Sources: Monero v0.18.5.3 release notes
2. Tor 0.4.9.14 security release announced
October 8, 2026 · Prompt security update at the briefing date
Affects Tor clients, relays, bridges and onion services.
Tor announced 0.4.9.14 as a security release affecting multiple operating roles. Operators needed to update the Tor package they actually ran, then confirm bootstrapping and service reachability. Updating Monero does not update a separately installed Tor daemon.
- Confirm the running Tor version after restart. Preserve configuration and check client connections or relay reachability as appropriate.
Sources: Tor 0.4.9.14 security announcement
Monero Research Lab — October 7, 2026
Reviewers found that an earlier fix in the experimental FCMP++ transition code was incomplete. The discussion concerned how legacy and Carrot outputs would be handled during a proposed grace period around the fork. Developers weighed dropping that grace period against keeping it with stronger checks. This concerned unreleased upgrade code, not a reported inflation event on mainnet.
Beta stressnet v3 had forked. Testing had produced large blocks, while reported GUI problems had known fixes still needing to be carried across. Developers also discussed enabling proof-tree code behind a build option so it could be tested without forcing unstable database work on every development build.
Longer eclipse-attack simulations reproduced the earlier defensive result. Rucknium was preparing the data and instructions needed to repeat the analysis. Results varied between runs, reinforcing the need for more than a single simulation.