AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Moderate 51 Cryptographic libraries

rpc: further restrict and clean up get_transaction_pool

Public commit record

What the developer wrote

Authored by selsta

50/100 · Thin
rpc: further restrict and clean up get_transaction_pool
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
The short version

What changed, and why it matters

This commit changes how Monero's public RPC endpoint 'get_transaction_pool' reports the contents of the memory pool (pending transactions). Previously, the endpoint could be called in 'restricted' mode and would hide some sensitive timing fields but still return transaction data. Now the endpoint always returns full timing metadata, but the entire method is blocked when the RPC is running in restricted mode. In short, the patch trades more complete data for a smaller attack surface: only trusted callers can query the transaction pool at all.

Recommended action

Operators running restricted RPC nodes should verify that get_transaction_pool is now unavailable to untrusted clients and that any monitoring tools using it are authenticated. Developers should review whether the unconditional exposure of receive_time/last_relayed_time to all internal callers (including the HTTP RPC path) is acceptable, or whether additional filtering should be reintroduced at the HTTP RPC layer rather than inside the mempool.

Security signals we found

01

Removal of sensitive-data flag from internal mempool query APIs

02

Unconditional exposure of receive_time and last_relayed_time to callers of get_transactions_and_spent_keys_info / get_pool_for_rpc

03

Addition of get_transaction_pool to restricted-mode blocklist in ZMQ RPC

04

core_rpc_server no longer distinguishes restricted vs unrestricted origins for this endpoint

05

Test updates show the API now always returns the full (all-category) set instead of a broadcast-only subset

Risk score

Why this scored 51/100

Our methodology →
Potential impact 12/30
Exploitability 8/25
Stealth signal 10/15
Affected reach 10/15
Confidence 7/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.