Bitcoin Core 32.0 has entered the candidate release testing. One of the security issues fixed in this release is not related to private key leakage, but to a node that has walletnotify enabled. It could potentially be triggered by a specially crafted wallet name to execute system commands.
The scenario isn’t complicated: a user who has already authenticated via RPC and has permission to create wallets sets a wallet name that has been constructed with a payload. When the relevant transaction appears, walletnotify will automatically run a preconfigured script. If the program does not strictly treat the wallet name as plain text, then any special characters could be interpreted as additional commands.
This doesn’t mean “Bitcoin has been compromised.” An attacker would first need RPC access to the node, and the node must also have walletnotify enabled. However, it reveals an attack path that is often overlooked: on-chain transactions are fine, private keys aren’t exposed, yet the vulnerability can still travel into the node host through RPC, the wallet name, and operating system scripts.
32.0 also improves fee estimation and block data reading. The new approach will draw more from the mempool’s real-time transactions, so fee recommendations can drop back faster after congestion decreases. The node can also read some data in parallel, speeding up block validation and synchronization.
When running a Bitcoin Core node, do not expose RPC directly to the public internet; disable any unnecessary walletnotify; and ensure any automated scripts use fixed parameters and the minimum required system permissions. Test candidate versions first in an isolated directory rather than directly replacing a production wallet.
Node security isn’t only about consensus and private keys—it also depends on which interfaces, scripts, and system permissions it connects to.
#Bitcoin #WalletSecurity #Node
The scenario isn’t complicated: a user who has already authenticated via RPC and has permission to create wallets sets a wallet name that has been constructed with a payload. When the relevant transaction appears, walletnotify will automatically run a preconfigured script. If the program does not strictly treat the wallet name as plain text, then any special characters could be interpreted as additional commands.
This doesn’t mean “Bitcoin has been compromised.” An attacker would first need RPC access to the node, and the node must also have walletnotify enabled. However, it reveals an attack path that is often overlooked: on-chain transactions are fine, private keys aren’t exposed, yet the vulnerability can still travel into the node host through RPC, the wallet name, and operating system scripts.
32.0 also improves fee estimation and block data reading. The new approach will draw more from the mempool’s real-time transactions, so fee recommendations can drop back faster after congestion decreases. The node can also read some data in parallel, speeding up block validation and synchronization.
When running a Bitcoin Core node, do not expose RPC directly to the public internet; disable any unnecessary walletnotify; and ensure any automated scripts use fixed parameters and the minimum required system permissions. Test candidate versions first in an isolated directory rather than directly replacing a production wallet.
Node security isn’t only about consensus and private keys—it also depends on which interfaces, scripts, and system permissions it connects to.
#Bitcoin #WalletSecurity #Node