Unauthenticated data disclosure on the Bridge State Machine (API) — MEDIUM

[DQiash]

Description

Multiple read endpoints of the bridge API return sensitive data with no authentication, including node identities, user bitcoin/EVM addresses, and instance metadata.

Affected component(s)

• bitvm-node — Bridge State Machine (API): bitvm2_handler.rs (get_unsigned_pegin_txn at :1757)
• Scope area: Bridge State Machine (API)

Steps to reproduce

Issue unauthenticated GET requests to the endpoints below against http://16.146.8.146:8901 with no Authorization header.

Proof of concept

Endpoint	Data returned
GET /v1/nodes	peer_id, actor, name, service_fee_rate, goat_addr (EVM), btc_pub_key, status
GET /v1/instances?is_bridge_in=true	instance_id, from_addr (user BTC), to_addr (user EVM), amount, status, user_xonly_pubkey
GET /v1/instances/{id}/unsigned-pegin-txn	no access control — PSBT field currently null

On the PSBT sub-claim, to avoid overstating: I scanned all nine bridge-in instances and every one returned {"pegin_prepare":null,"pegin_cancel_psbt":null}. The handler at line 1757 only populates the PSBT when the instance status is in {CommitteesAnswered, UserBroadcastPeginPrepare, Presigned, PresignedFailed, Timeout}. All current instances are pre-stage, so nothing leaks today. The endpoint is unauthenticated (a real flaw), but the PSBT exposure is latent/conditional and only becomes exploitable when an instance reaches a late-stage status. I am reporting the metadata disclosure as confirmed live and the PSBT case as a conditional exposure.

Security impact

Exposure of node identifiers, fee rates, EVM addresses, and user BTC/EVM addresses plus user x-only public keys. Combined with Finding 1, an attacker can enumerate and monitor the full set of bridge instances and the operator's identity. Recommended fix: require authentication for all read handlers that expose instance or node metadata, and add access control to get_unsigned_pegin_txn.