Auth signature does not bind method, path, or body — LOW/MEDIUM

[DQiash]

Description

In bitvm-node/node/src/rpc_service/auth.rs, the authentication hash covers only the auth domain (b"bitvm2-auth") and the timestamp string. It does not bind the HTTP method, path, or body, so a valid signature can be replayed across endpoints within the 300-second replay window (AUTH_WINDOW_SECS).

Affected component(s)

• bitvm-node — rpc_service/auth.rs
• Scope area: Bridge State Machine (API)

Steps to reproduce

1. Capture a valid signed request (e.g. pegout).
2. Within the 300s window, replay the same signature against send_challenge (or vice versa).

Proof of concept

hasher.update(AUTH_DOMAIN);            // b"bitvm2-auth"
hasher.update(timestamp_str.as_bytes()); // does not bind method/path/body!

Security impact

Cross-endpoint signature replay within the replay window. An attacker cannot forge a signature; they must intercept a valid one in the window, so this is Low/Medium. Recommended fix: include method, path, and a body hash in the signed payload.

---

[mr-hrydarie]

Confirmed independently, with a runnable integration test that pins the exact behavior your report describes. Filed as reinforcement, not a duplicate claim.

Two additions to what you wrote:

1. The domain string is bitvm-auth, not bitvm2-auth. Verified at node/src/rpc_service/auth.rs line 12: const AUTH_DOMAIN: &[u8] = b"bitvm-auth";. The signed digest is SHA256(b"bitvm-auth" || timestamp_str).

2. The replay is not limited to the auth window; it wedges the watcher permanently when combined with a planted instance ID. The unbound digest lets a sniffed pair authenticate any method and path within the window (I confirmed GET plus two PUT endpoints). The stronger consequence sits one layer down: an authenticated attacker can call postPeginRequest with a caller-chosen instanceId, and planting the publicly derivable bridge-out ID of a future withdrawal freezes the bridge-out processing cursor on its error branch across restarts. Reproduced against the real store code at commit 460d39e: cargo test -p store --test poc_bridge_out_id_collision, 3/3 pass (plant + collision bail!, cursor frozen after failed handler, negative control clean).

Runnable PoC for both layers:

• Test source and run logs: https://gist.github.com/mr-hrydarie/c570e0b0c85f033f13117bb13c884219
• Auth replay PoC: poc/poc20_auth_unbound.rs (isolated crate including production auth.rs verbatim), 8/8 pass: one sniffed pair authenticates GET and PUT endpoints inside the window, negative controls reject.
• Cursor wedge PoC: poc/poc19_bridge_out_id_collision.rs, run log poc/poc19_run.txt.

Live corroboration, read-only, 2026-08-25: all 11 bridge-out instances at https://bitvm3-api-testnet4.goat.network/v1/instances?is_bridge_in=false&limit=50 match the derivation UUID(SHA256("bridge-out:" || escrow_hex)[..16]) with ASCII BOID overwrite (node/src/utils.rs lines 138 to 151), confirming the target namespace an authenticated planter would hit. No live writes were performed.

Fix suggestions, matching yours plus two: bind method and path into the signed document (or use a challenge-response nonce per connection), shorten the window below any operational retry interval, derive instance IDs server-side, and dead-letter records whose handler errors instead of freezing the cursor.

Submitted under the GOAT BitVM3 bug bounty campaign as independent confirmation with additional impact.