Unauthenticated state write on the Bridge State Machine (API) — MEDIUM

[DQiash]

Description

The bridge node exposes sixteen public handlers in bitvm-node/node/src/rpc_service/handler/bitvm2_handler.rs, but the authentication function verify_request_auth() is only invoked on two of them: send_challenge (line 1814) and pegout (line 1869). The remaining fourteen handlers (bridge-in/out instance creation and state transitions) run with no authentication middleware, so any unauthenticated client can create and mutate bridge instance state.

Affected component(s)

• bitvm-node — Bridge State Machine (API): bitvm2_handler.rs (16 pub handlers; only :1814 and :1869 call verify_request_auth())
• Scope area: Bridge State Machine (API)

Steps to reproduce

1. Start bitvm-node testnet4 (operator node at http://16.146.8.146:8901).
2. Issue a PUT /v1/instances/bridge-in-request-tag request with no Authorization header and a valid body.
3. Observe a 200 OK response and, on subsequent reads, that the instance was created.

Note on the request body: use from_addr = tb1qhzjkeeu3yz3kwnzmrkrerpmatgp7xp6eqxunsl. The default script value tb1qw9m4...r6t is an invalid SegWit address and returns 400 INVALID_BTC_SEGWIT_ADDRESS.

Proof of concept

PUT /v1/instances/bridge-in-request-tag
HTTP/1.1 200 OK
{}

→ instance created: "instance_id":"00000000-0000-4000-8000-00000000cea3"

The request above carried no Authorization header and still ran successfully on the live testnet4 node.

Security impact

An attacker can create bridge-in/bridge-out instances arbitrarily, polluting the node database and tainting the displayed bridge-out to_addr / amount metadata. This is data-integrity and state-consistency compromise rather than direct theft, because on-chain state is the source of truth for funds and cannot be forged via the API alone. Recommended fix: enforce verify_request_auth() via a global middleware, or add it to every non-public handler.