Monero

This small Monero patch fixes a notification bug in the transaction pool. When a privacy-protecting 'stem' transaction is later re-broadcast as a normal 'fluff' transaction, the code now correctly reports the updated relay method to external listeners (such as the ZMQ event stream). Previously, the notification used the original relay method, which could mislead external tools about how the transaction was actually being relayed. There is no direct evidence this enables theft or remote code execution, but it could confuse monitoring systems or weaken privacy-related analytics.

This patch fixes a bug in how Monero announces new mempool transactions over its ZeroMQ publish (ZMQ-PUB) interface. Before the fix, transactions that first arrived in a privacy-preserving 'stem' phase were incorrectly announced as if they were ordinary public mempool transactions, potentially leaking information about transaction timing or origin. The fix now only sends the ZMQ notification when the transaction is genuinely being broadcast publicly for the first time.

This commit adds a safety check when building Monero transactions to make sure any 'change' output (leftover funds returned to the sender) actually belongs to the sender's wallet. Before this change, a wallet or tool could accidentally specify a change address it did not control, sending leftover funds to a stranger or attacker. The fix re-derives the change address from the wallet's keys and rejects the transaction if it does not match. It is a defensive hardening measure rather than a fix for an active remote exploit.

This commit only fixes spelling mistakes in comments and log messages. No code behavior was changed, so it has no security impact.

This commit fixes command-line handling in Monero's blockchain utility programs. It makes sure the --data-dir option works correctly with the newer --regtest network mode, and centralizes the logic that decides which network type (mainnet, testnet, stagenet, or regtest) is being used. It is a code-quality and correctness fix rather than a security patch for an exploitable vulnerability.

This change refactors how a Monero node cleans up after receiving blocks. Previously, every early-exit path had to remember to call a cleanup routine and remove a queued block span; now a single scope-exit handler does it automatically. The main risk is that any path that used to skip cleanup now runs it, or that the new handler runs in a different order with surrounding code. The patch appears intended to prevent resource leaks or stuck block queues when a peer misbehaves or the node is shutting down.

This small code change converts a function that computes a pruned transaction hash from one that throws exceptions on failure to one that returns a success/failure boolean. Callers now check that boolean and stop processing if the hash could not be calculated. The main practical effect is to prevent malformed or version-1 pruned transactions from causing unhandled exceptions or being processed with an unset hash, which could lead to denial-of-service or incorrect wallet/node behavior.

This commit adds exception handling around two network callback functions and changes one block-queue function to log errors instead of throwing exceptions. It appears aimed at preventing unhandled exceptions from crashing or destabilizing network connections during message processing. The change is defensive and does not obviously introduce a security vulnerability, but it is only a partial hardening patch.

This commit adds a security check to the Monero wallet's remote-control interface (RPC server). It now refuses the 'relay_tx' command when the server is running in 'restricted' mode. Before this change, a user or attacker with RPC access could potentially ask a restricted wallet to broadcast a transaction it had prepared, which restricted mode was apparently meant to prevent. The fix is small and defensive, but the commit message does not explain whether this was an actual bug or just a hardening measure.

This commit fixes a bug in the Monero wallet's remote procedure call (RPC) server where SSL certificate fingerprints provided by users were not being properly decoded from hexadecimal text into raw bytes. Previously, the code treated each character of the hex string as a separate byte, which meant the fingerprint comparison would almost always fail or behave unpredictably. The fix properly decodes the hex string and validates its length. This is a security-relevant correctness bug because it could prevent certificate pinning from working as intended, but the commit itself does not describe an active exploit or vulnerability disclosure.

This commit adds two safety checks to the Monero wallet code that parses multisig transactions. It now rejects multisig transactions that have no inputs ('vin') and no 'sources'. Without these checks, a malformed or malicious multisig transaction string might have been accepted for further processing, potentially causing crashes, incorrect signing behavior, or confusion in the multisig workflow. The change is small and defensive.

This change only modifies a test script for Monero's automated functional tests. It replaces one way of setting up test blockchain state (mining through a wallet) with another (generating a block directly via the daemon and rescanning the wallet). It also makes two test assertions more explicit about expecting a connection to be rejected. There is no change to the actual Monero node, wallet, or RPC authentication code that users run, and nothing here suggests a security vulnerability or fix in production software.

This commit tightens limits on a Monero RPC command called add_aux_pow that is used to add auxiliary proof-of-work data. When the RPC server runs in restricted mode, it now rejects requests with more than 10 auxiliary hashes and lowers the maximum nonce search from 65,535 to 16,384. The change appears aimed at preventing a restricted/public RPC endpoint from being abused to perform expensive CPU or memory work, which could be used to slow down or overload a node.

This patch fixes a configuration bug where Monero's regression-test mode (regtest) was accidentally sharing its data folder and peer list with the real main network. Before the fix, someone running a local test chain could read or overwrite the same on-disk peer state used by mainnet. The patch makes regtest use its own separate 'fake' subdirectory and ensures regtest nodes do not try to contact mainnet seed nodes. It is a hardening fix for test/mainnet isolation, not a remote exploit.

This patch fixes a security gap in Monero's wallet RPC server when it runs in '--restricted-rpc' mode. That mode is meant to block sensitive wallet commands from remote callers, but several methods were checking whether a wallet was open before checking the restricted flag. A remote attacker could therefore call those methods on a restricted RPC server and trigger errors or behavior that should have been blocked outright. The fix moves the restricted-mode check to the very beginning of each sensitive command so it is denied immediately.

This one-line change fixes a logic bug in how Monero wallets detect 'background wallets' when verifying a password. The old code accidentally treated a JSON parsing failure as evidence that a wallet was a background wallet, and treated successful JSON parsing as evidence it was not. The fix reverses that logic. A background wallet is a special wallet type that lacks a private spend key. Because of the bug, a normal wallet with a valid JSON account record could be misclassified as a background wallet, which could lead the software to skip required spend-key checks or allow operations that should require the spend key. The actual security impact depends on how downstream code uses the no_spend_key flag, but the change clearly corrects an inverted condition that has security-relevant consequences.

This change adds an optional flag to Monero's multisig wallet import process that lets callers skip the automatic wallet refresh and spent-output rescan. By default the refresh still happens, so existing behavior is preserved. The patch is a usability/performance improvement rather than a fix for an active security flaw, though skipping refresh could in theory leave a wallet with slightly stale balance information if used carelessly.