Cowrie Research

slope-wallet-mobile-sentry-private-key-telemetry-leak-drain-2022-08-02

14 min read

Slope Wallet Mobile Sentry Private-Key Telemetry Leak Drain (2022-08-02)

  • Name: Slope Wallet mobile Sentry private-key telemetry leak drain
  • Date: 2022-08-02
  • Protocol: Slope Wallet
  • Chain: Solana (with Ethereum wallets also exposed where the same BIP39 mnemonics were reused)
  • Category: wallet-secret leakage / observability-boundary failure / debug-telemetry exfiltration / mobile-wallet incident
  • Loss: about 9,231 wallets drained for roughly $4.1M over about four hours, according to Solana’s incident notice
  • Summary: This incident was not a Solana protocol break and not an onchain smart-contract exploit. Attackers signed normal wallet-drain transactions with real user keys. The strongest public root-cause trail pointed to Slope Wallet’s mobile applications, which had transmitted sensitive wallet material to a Sentry-based application-monitoring pipeline. Solana’s security notice stated that affected wallets had at one point been created, imported, or used in Slope and that private-key material from Slope users was inadvertently sent to an application monitoring service. Slope’s later incident report confirmed a grave Sentry logging vulnerability — including wallet private keys stored unencrypted on a central server during the vulnerable period — but argued that the available forensics could not conclusively prove that this logging path alone explained every drained wallet. The preserved lesson is still clear even with that residual uncertainty: once a wallet lets mnemonic or private-key material cross into crash reporting or telemetry, the observability stack becomes part of the effective custody boundary.
  • Trigger / entry point:
    • Slope’s iOS and Android wallet apps used Sentry-style application monitoring in code paths that could see imported or generated secret material.
    • Slope’s later report says version 2.2 added a toString() path on 2022-06-24 that bypassed Sentry blacklist filtering for sensitive parameters, while separate development changes also collapsed the app’s expectation that logged data would remain ciphertext.
    • The Solana Foundation’s public incident update said affected wallets were linked to Slope usage and that private-key material had been inadvertently transmitted to an application monitoring service.
    • Slope’s own later report said its self-hosted Sentry pipeline on AliCloud resumed Kafka-backed logging on 2022-07-28, creating a seven-day server-side exposure window that ended only when the application-monitoring server was shut down on 2022-08-03.
  • Root cause:
    • Wallet-secret material was allowed to cross from the mobile signing environment into an observability / telemetry system that should never have been part of secret custody.
    • Redaction / filtering assumptions were too weak. Slope’s report says a later-added toString() path bypassed Sentry blacklist filtering and caused sensitive parameters to be logged.
    • The telemetry pipeline and its storage model were not engineered as mnemonic custody infrastructure even though the application had started feeding them signer-equivalent material.
    • Public attribution retained some uncertainty about the exact theft path for every victim, but the decisive design failure was still the same: secrets escaped the wallet boundary into monitoring infrastructure.
  • Exploit path:
    1. Slope mobile wallet code handled mnemonic or private-key material during wallet creation, import, and wallet-selection / signing-adjacent flows.
    2. Routine debugging changes let Sentry capture more state than intended: Slope says a toString()-based parameter concatenation path in version 2.2 bypassed blacklist filtering, while plaintext processing choices for encrypted messaging weakened the assumption that sensitive data would stay unreadable end to end.
    3. When Slope’s self-hosted Sentry pipeline resumed on 2022-07-28, secret-bearing mobile logs began landing on Slope-controlled backend infrastructure; Slope’s later report says 6,811 unique wallet private keys were found on the Sentry database and that 5,367 of those wallets were not drained during the August 2 attack.
    4. At 2022-08-02 22:37 UTC, attackers began using real compromised keys to sign drains from affected wallets. Solana’s public notice says the draining continued for roughly four hours; Slope’s later report describes a roughly seven-hour window ending around 2022-08-03 05:50 UTC.
    5. The drain pattern itself showed valid wallet authority rather than a protocol-level exploit: malicious transfers were properly signed, which is why investigators quickly focused on key leakage rather than consensus or contract failure.
    6. Forensics later complicated the easy story: Slope reported that only 5,033 of the 9,229 drained wallets could be traced to any prior Slope mobile interaction, and only 1,444 drained wallets had private keys found in the Sentry database. That preserved uncertainty about whether the Sentry leak explained the entire victim set even while confirming that the telemetry path itself was a grave signer-secret breach.
    7. Cross-wallet fallout reached users of Phantom and Solflare too when they had reused seed phrases that had previously been imported into Slope, reinforcing that the signing authority itself had leaked rather than one wallet implementation being remotely exploitable on its own.
    8. Investigators identified Slope’s Sentry implementation during incident response on 2022-08-03; Slope says the monitoring server was shut down at 11:45 UTC, after which the ecosystem response shifted into emergency migration and users were told to abandon old seed phrases and transfer assets to fresh wallets.
  • What the attacker needed to be true:
    • Sensitive key material had to leave the local wallet boundary and become observable somewhere else in the logging / telemetry path.
    • The leaked material had to remain usable as live signing authority rather than being wrapped in hardware isolation or another non-exportable key layer.
    • Users had to still hold funds in wallets derived from affected mnemonics at the time of the drain.
    • Some victims had to reuse the same BIP39 seed across different wallet apps, letting a Slope-linked leak become theft from non-Slope wallet interfaces too.
  • Technical anatomy worth remembering:
    • The onchain theft transactions were not exotic. The important forensic clue was that they were validly signed, which collapsed the problem toward key compromise rather than protocol logic bugs.
    • This is a strong observability became custody case. The dangerous system was not only the wallet app, but the crash-reporting and monitoring path the app was allowed to feed.
    • The Slope report preserves a useful timeline split between client-side collection and server-side exposure: secret-bearing client changes began with version 2.2 on 2022-06-24, but the server-side vulnerability window only became live when Kafka-backed logging resumed on 2022-07-28.
    • Slope’s own reconstruction says four nominal safety layers existed — collection filters, TLS transport, encrypted storage, and access control — yet two ordinary development mistakes still defeated the first and third layers. Self-hosting the telemetry stack did not make it meaningfully safer once signer-equivalent material entered it.
    • Solana’s initial public notice and Slope’s later report differ in confidence: Solana treated the Slope telemetry leak as the operative explanation for affected wallets, while Slope’s post-incident report said the known Sentry vulnerability did not conclusively explain every drained wallet. The note should preserve that ambiguity rather than pretending the public record is cleaner than it is.
    • The residual uncertainty does not weaken the architectural lesson. A wallet that ever ships mnemonic or private-key material into telemetry has already broadened its trust boundary beyond the signer surface users think they are trusting.
    • Hardware wallets escaped because the replayable secret never entered the same mobile application memory / telemetry path in the first place.
  • Representative control points:
    • Affected wallet provider: Slope Wallet mobile applications (iOS and Android)
    • Monitoring surface identified publicly: Sentry-based application monitoring / logging pipeline used by Slope mobile apps
    • Solana public incident count / loss estimate: about 9,231 wallets and about $4.1M
  • Response / mitigation:
    • Solana publicly stated that this was not a protocol-level Solana vulnerability and warned any Slope user — or anyone who had ever imported a seed phrase into Slope — to migrate funds to newly generated wallets.
    • Slope says the incident-response team identified its Sentry implementation as a credible exposure path at 2022-08-03 11:30 UTC and shut down the monitoring server at 11:45 UTC.
    • Slope later pulled its mobile applications from the iOS and Android stores on 2022-08-05 and published a more detailed incident report.
    • Users were instructed to abandon all seed phrases that had been used with Slope mobile apps, because merely fixing the logging bug could not un-leak already exposed signing material.

Pattern tags

  • secret-material-observability-leakage-debug-telemetry-exfiltration
  • wallet-secret material escaped into crash reporting / telemetry
  • self-hosted monitoring became effective custody infrastructure
  • seed reuse widened one wallet-vendor leak into cross-wallet / cross-chain theft

Why the exploit worked

  • Slope’s mobile signing environment allowed replayable secret material to become ordinary observable application data. Once that happened, the real trust boundary was no longer just wallet app -> local secure storage; it also included serializers, telemetry SDK hooks, Kafka-backed logging, and the Sentry database.
  • The vulnerable period had two separate gates, and both eventually opened: the client-side toString() path added on 2022-06-24 weakened Sentry-side filtering, and the resumed server-side Kafka logging on 2022-07-28 turned that weaker capture path into a live central-store exposure window.
  • The attacker did not need a Solana consensus break, a smart-contract bug, or a wallet-UI spoof. The drained transactions were validly signed, so any path that surfaced usable mnemonic or private-key material was already enough to cash out funds directly.
  • Transport and hosting controls were the wrong layer to rely on. HTTPS, TLS pinning, self-hosting, encrypted-at-rest assumptions, and access control could not repair the earlier architectural mistake that signer-equivalent material had entered observability tooling at all.
  • Seed reuse amplified the incident beyond Slope’s own interface. Once one BIP39 mnemonic had been imported into Slope, that same leaked authority could later drain Phantom, Solflare, or Ethereum-side wallets derived from the same seed.

Detection and audit pivots

  • Treat validly signed drains as an immediate secret-compromise pivot, not an onchain-mechanics mystery. The first question is which wallet, signer, telemetry, import, or support surface ever saw replayable authority?
  • Reconstruct the full timeline as two distinct exposure boundaries: client versions that could collect secret-bearing state (2.2, then 2.2.1) and server periods when Sentry / Kafka actually persisted those events (2022-07-28 through shutdown on 2022-08-03).
  • Query every telemetry, crash-reporting, and support store for mnemonic-looking strings, base58 / base64 key material, wallet-import payloads, and private-key-shaped blobs. The important audit question is not only was data encrypted? but did replayable authority ever land here at all?
  • Correlate drained wallets against prior Slope mobile creation, import, and usage history, but keep the exposed-set and drained-set distinct. Slope’s own later counts (6,811 keys on the Sentry database, 1,444 of them in drained wallets, 5,033 drained wallets traced to any Slope interaction) are exactly the sort of split that matters during incident reconstruction.
  • Sweep for sibling blast radius outside the originating app: other wallets or chains using the same BIP39 mnemonic, imported recovery phrases, and any shared secure-backup or support flows that may have preserved the same signer authority elsewhere.

Failure-prevention checklist

  • Keep mnemonic, seed, and raw private-key material out of generic observability surfaces entirely. Crash reporting, analytics, traces, support bundles, and debug serializers should never be able to observe replayable signing authority in the first place.
  • Treat secret-bearing mobile code paths as telemetry-exclusion zones by default. Wallet creation, import, seed recovery, signing preparation, and key-export-adjacent flows should either disable third-party monitoring hooks outright or pass only pre-scrubbed, schema-limited events.
  • Make redaction structural rather than keyword-based. toString() surprises, error-object serialization, and nested parameter logging should fail closed if they encounter secret-bearing types instead of relying on blacklist folklore.
  • Keep replayable authority in non-exportable or tightly scoped storage when possible, and minimize how often it ever exists in ordinary application memory.
  • Separate secret collected nowhere from secret collected but transported safely. HTTPS, certificate pinning, server access control, and encrypted storage are not meaningful compensating controls if the system already copied signer-equivalent material into telemetry.
  • Give operators a one-switch kill path for monitoring and analytics on signer-adjacent surfaces. If telemetry is suspected, the first response should be immediate shutdown and key-rotation guidance, not hours of debate over whether the logs were probably secure enough.
  • Treat every confirmed signer-secret observability breach as a migration event. Once mnemonic or private-key material may have escaped, the protocol response has to assume seed rotation, asset migration, and downstream-wallet exposure across any app that reused that seed.
  • Design user guidance around seed reuse reality rather than ideal behavior. If one wallet app supports the same BIP39 mnemonic used elsewhere, a leak in that app can become theft from multiple wallets and chains.

Audit prompts

  • Which exact mobile or wallet code paths ever handle mnemonic phrases, private keys, seed bytes, decrypted key material, or signing-ready payloads, and what third-party SDKs are live in those paths?
  • Can any error object, debug serializer, toString() helper, crash reporter breadcrumb, analytics payload, or support bundle accidentally stringify or snapshot secret-bearing state?
  • Are telemetry filters type-aware and deny-by-default for secret-bearing objects, or do they still rely on field names and keyword blacklists that routine refactors can bypass?
  • What proof shows replayable authority never leaves secure storage except for the shortest necessary signing window, and what prevents that window from overlapping with observability hooks?
  • If secrets ever did reach a monitoring backend, how quickly could operators disable collection, bound the exposure window, and tell users to rotate wallets rather than merely patch the client?
  • Which downstream ecosystems inherit the blast radius if this wallet leaks one seed: sibling wallets, other chains using the same mnemonic standard, browser extensions, or imported hardware-wallet recovery paths?
  • Do incident runbooks distinguish bug fixed from seed material already irreversibly exposed, and do they default to wallet migration when the latter may be true?
  • Are self-hosted telemetry servers being treated as if they were secret-safe by virtue of access control, even though the more important question is why signer-equivalent material was allowed in them at all?

Lessons that should already be standard

  • Observability systems become custody systems the moment replayable secrets enter them. From that point on, crash reporters and log pipelines deserve the same paranoia as signing infrastructure.
  • We self-hosted it is not a defense. Slope shows that HTTPS, certificate pinning, server access control, and encrypted storage do not rescue a design that already copied keys into telemetry.
  • Redaction folklore is weaker than secret non-observability. Keyword filters and blacklist assumptions routinely lose to innocent serialization changes.
  • Wallet incidents do not need an exotic onchain primitive to be catastrophic. Valid signatures from leaked keys are enough.
  • Inconclusive forensics about the full victim set do not soften the confirmed design failure. Once one grave secret-handling breach is proven, the architectural lesson already stands.
  • Seed reuse turns one wallet-vendor mistake into a broader ecosystem incident. A compromise in one client can drain users from other wallet interfaces and other chains if the same mnemonic traveled there.
  • The right emergency action after possible signer-secret leakage is migration, not reassurance. Users need new wallets, not just a patched app.

Why this incident matters

  • It preserves a wallet-side failure mode that is easy to under-document because there was no elegant onchain exploit primitive. The money moved because observability boundaries, not contract code, failed.
  • It is a clean reminder that mobile wallet telemetry, analytics, and debug tooling are part of the custody surface whenever raw keys or mnemonics can touch them.
  • It is also the clearest wallet-side exemplar for replayable-secret non-observability and telemetry-exclusion discipline: the real architectural mistake was letting replayable signer authority become ordinary observable app data before self-hosting, transport encryption, or post-hoc filtering could matter.
  • It also preserves an important analytical caution: public investigations may remain partially inconclusive even when one serious key-handling failure is obvious. That uncertainty should not be used to soften the severity of the known design mistake.

Internal linkages

Control surface

Graph View

Backlinks