Hardhat node RPC exposed on all interfaces when using --hostname 0.0.0.0 without warning

Short answer

Yes — Hardhat should warn when hardhat node binds its JSON-RPC server to 0.0.0.0 (or any non-loopback address), because the local development node has no RPC authentication and its pre-funded test accounts are spendable by anyone who can reach the port. The silence today is not a statement that the setup is safe; it reflects that --hostname is treated as an explicit networking choice, optimized for Docker, CI, and LAN testing workflows.

What's confirmed vs. likely

Confirmed baseline: Hardhat's local node is development-oriented and conventionally binds to 127.0.0.1:8545. Passing --hostname 0.0.0.0 changes the listener from loopback-only to all local interfaces, and the CLI proceeds without flagging the exposure.

Likely explanation: the flag is assumed to be deliberate, so the CLI avoids friction. That assumption holds for experienced users but breaks down when 0.0.0.0 is copy-pasted from a Docker tutorial into a context where it isn't needed — a very common path to accidental exposure.

Important caveat: 0.0.0.0 is not automatically public

Binding to all interfaces changes potential reachability, not actual reachability. Real exposure depends on your firewall, router/NAT, cloud security groups, Docker port publishing (-p 8545:8545), WSL2 networking, and VPN interfaces. The dangerous combinations are 0.0.0.0 plus a published container port, a permissive cloud workspace, or a bridged VM — that's when other hosts can call eth_sendTransaction against unlocked dev accounts.

Answering the three design questions

1. Should the CLI warn on --hostname 0.0.0.0? Yes. A warning should fire for 0.0.0.0, ::, or any non-loopback bind, state that RPC is unauthenticated and development accounts are spendable, and then let the run proceed. Non-breaking, near-zero cost.
2. Should hardhat.config.js offer a localhost-only enforcement option? Reasonable as an opt-in team policy — e.g., a setting that rejects non-loopback binds unless a script explicitly overrides it. It must not be enabled silently, or it will break legitimate Docker, CI, device-testing, and remote-debug workflows.
3. Should the default change to require explicit opt-in for public access? That's a breaking-change decision. The current default is already loopback; the flag itself is the opt-in. Making public binding harder (e.g., a separate --expose flag) belongs in a major release, not a patch.

Verify your actual exposure

Don't infer reachability from the bind address — test it:

# Start the node and watch for any warning before accounts are listed
npx hardhat node --hostname 0.0.0.0

# Confirm the listener (Linux)
ss -ltnp | grep 8545   # expect 0.0.0.0:8545, not 127.0.0.1:8545

# From a second host or container namespace, test real reachability
curl -s -X POST http://<host-ip>:8545 \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

If the eth_chainId call succeeds from another machine, treat the node as exposed and either rebind to 127.0.0.1 or restrict the port with firewall rules / security groups.

Practical recommendation

The best near-term behavior is non-breaking: emit a clear warning on any non-loopback bind, document how Docker port mapping and NAT interact with 0.0.0.0, and defer mandatory opt-in to a major version. Note that whether a given Hardhat release already prints such a warning varies — check your installed version's CLI help (npx hardhat node --help) and changelog rather than assuming.