Public Telemetry Endpoint Leaks Bitcoin Wallet Master Keys

Reported Feb 21, 2026

Severity Critical

Platform Web

Vulnerability Class Sensitive Data Exposure (CWE-200)

Target Type Self-Custody Wallet Provider

Impact 3,200+ user wallet master keys exposed

The Risk

A monitoring page on the wallet provider's production servers, normally only ever read by their own engineers, was open to anyone on the internet. Hidden inside that page were thousands of master keys belonging to real customers' Bitcoin wallets. With one of those keys an attacker can permanently watch every coin a user receives or spends, going back through their entire history and forward forever, even if the user never returns to the wallet app. Over three thousand customers were exposed in a single download.

The Vulnerability

A monitoring endpoint used by the operations team for production telemetry was reachable on the public internet without authentication. The endpoint returned HTTP 200 to any client and emitted text-format metrics for the production API.

The instrumentation captured the raw HTTP request path as a label on each metric. The wallet API uses paths shaped like /api/v1/account/<extended-public-key>, so the user-identifying portion of the URL was being recorded into a label rather than normalized to a template such as /api/v1/account/:pubkey. This is a classic high-cardinality label anti-pattern, and in this case the high-cardinality value was a sensitive customer identifier.

The Attack

Reproduction was a single unauthenticated request followed by a regex extraction.

curl -s -o /dev/null -w "%{http_code}\n" \
  https://[redacted-host]/metrics
# expected: 200

curl -s https://[redacted-host]/metrics \
  | grep -oE '(xpub|ypub|zpub)[A-Za-z0-9]+' \
  | sort -u | wc -l
# expected: thousands of unique values

Why These Identifiers Matter

Although on-chain transactions are public, an extended public key is not stored on-chain. It typically only exists inside the wallet software itself. With this key an attacker can deterministically derive every receiving and change address the wallet has used or will use, and then monitor balances and transactions indefinitely. The telemetry also revealed that each wallet was queried via this provider, which is itself information that does not appear on the chain.

The Impact

Approximately 3,200 unique Bitcoin extended public keys observed in a single response
Permanent wallet surveillance for every leaked key, covering past and future activity
Correlation of wallets to provider usage, breaking the privacy model users expect from a self-custody product
The same instrumentation pattern affected a sibling API on a separate chain, multiplying the customer base impacted

Remediation

Restrict the metrics endpoint to internal networks only, or place it behind authentication.
Normalize routes to templates such as /api/v1/account/:pubkey before recording them as labels. Never emit raw user identifiers as label values.
Drop the route label entirely if templating is not feasible for this metric.
Add an automated check that scans telemetry output for known sensitive patterns (extended public keys, wallet addresses, transaction IDs) before deploys reach production.
Audit existing metrics scrape targets and historical metric backends for retained sensitive labels.