Core release

A wallet name should not run a command

Updated 30 September 2026

On 14 September 2026, the first release candidate for Bitcoin Core 32.0 was tagged. Among the changes is one that should not have needed to be written: a wallet name is now treated as a string, not as a command. That sounds like nothing. It is not nothing. On a non-Windows node where someone had enabled walletnotify and an RPC user had permission to create wallets, a deliberately chosen wallet name could already be a command. That has been the case since Bitcoin Core 24.0.

What the flaw was

Bitcoin Core lets an operator define walletnotify: a command that runs on the host when a wallet transaction is seen. On 14 September 2026, CoinDesk reported that Bitcoin Core 32 fixes a flaw present since 24.0 on non-Windows systems, where an authenticated user with permission to create wallets could give one a crafted name and cause commands to run on the host.

Three things had to line up. The attacker needed wallet creation over RPC, which most exposed setups grant to anyone reaching the JSON-RPC port. They needed a non-Windows host, so the wallet-name expansion happened through a shell. And they needed walletnotify enabled, which on a node reacting to transactions is the default.

Why wallet names touched the shell at all

walletnotify was always run by a shell, on Linux and macOS. Bitcoin Core handed the configured command template, with the wallet name interpolated, straight to the system shell. That made sense when the operator controlled both ends.

The problem is that wallet creation, on a permissive RPC setup, is not always the operator. A wallet name is a label, not a security boundary. The fact that the string got handed to a shell was a long-standing convenience. The fact that an RPC user could pick it was an oversight that took eight years to fix.

Who was actually exposed

You were exposed if all three were true: a non-Windows node, walletnotify configured to a real command rather than the no-op default, and RPC access to wallet creation that an attacker could reach. Public-facing RPC is rare. Many operators listen on loopback or behind a firewall.

It is not zero. Some home setups forward the RPC port by mistake. Some operator stacks run a sidecar that creates wallets for multiple users. Any of those is a place where a wallet name ending in a shell metacharacter could have been code, rather than a label, for the entire lifetime of Bitcoin Core 24 through 31.

What 32.0 changes

Bitcoin Core 32.0 treats wallet names as literal text instead of allowing parts of the name to be interpreted as commands. The change does not require any operator action beyond upgrading. Existing wallets keep their names. The walletnotify feature keeps working.

Pluang's coverage of the release candidate on 14 September 2026 noted about 60% of reachable nodes currently run versions that will no longer receive security fixes once 32.0 ships. The same RC also drops eight database threads into block validation by default and replaces the long-standing HTTP server, which carries its own fix to a memory-exhaustion flaw found during an audit by Moonshot AI's Kimi K3 model.

What an operator does today

Wait for 32.0 stable on 10 October, then upgrade. The release schedule is on the project's issue tracker, and the RC tag is the marker that the feature set is frozen. The existing walletnotify path on Bitcoin Core 24 through 31 still runs the wallet name through a shell, so upgrading is what closes the gap.

If you operate a public-facing node, the more useful upgrade pattern is the one this kind of flaw exists to remind you about. Keep RPC behind authentication. Keep it off the public internet. If you need to expose it, do it through a sidecar that does not have permission to create wallets on the host itself. None of those are new pieces of advice, and all of them are what the wallet-name flaw makes worth repeating.

Bitcoin protocol information, not custody advice. Verify any address or transaction before acting on it.