Crypto Exchange Android App Leaks 30-Day Session Token to Third-Party Chart Provider
The Risk
Every time a logged-in customer of a centralized crypto exchange viewed a meme coin chart in the Android app, the app silently handed their full 30-day session over to a third-party charting service in plain HTTP request headers. That session worked from any computer, anywhere, with no second factor required, and let the holder read the customer's email and balances and place trades on their account. The same leak happened when users opened the staking screen or used "Login with Telegram", quietly putting customer sessions into multiple unrelated companies' server logs.
The Vulnerability
The Android app's central WebView wrapper unconditionally injected the user's full 30-day session token as an HTTP request header on every URL it loaded, with no domain check. Any third-party content embedded inside an in-app WebView received the token automatically.
The relevant code path attached two headers to every WebView request:
// WebView wrapper, simplified
map.put("auth-token", commonParams != null ? commonParams.getToken() : "");
map.put("x-device", "Android");
webView.loadUrl(url, map);
// No domain check. Every URL receives the token.The desktop website was tested with the same flow and was not affected. The browser correctly loaded the third-party chart in an iframe without sending any of the exchange's auth headers. This confirmed the leak was a defect in the Android WebView wrapper, not intended behavior.
Other affected screens
Static analysis of the same WebView wrapper identified two more triggers that fired during normal app use:
- Navigating to the on-chain staking screen, which loaded a third-party staking analytics domain
- Tapping "Login with Telegram", which loaded the Telegram OAuth domain
Both screens received the same auth token in HTTP headers.
The Attack
This finding required no attack. The leak happened automatically during normal use. To confirm and capture the leaked token in a controlled environment:
- A rooted Pixel 5 was set up with a system-trusted CA certificate and traffic routed through a proxy
- SSL pinning in the app was bypassed at runtime so request bodies and headers were visible in plaintext
- The user opened the on-chain tab inside the app and tapped any meme coin to load its chart
- The chart widget loaded from a third-party charting domain. The full session token rode along in the request headers, captured by the proxy
The captured request showed the session token, a device binding ID, and a base64 device-info blob, all sent to a third-party origin that has no relationship with the exchange's authentication.
The Impact
To prove the leaked token was usable, it was copied from the proxy capture and replayed from a VPS on a different network and country. Confirmed actions with the captured token:
| Action | Result |
|---|---|
| Read user profile (email, ID, 2FA status) | Full PII returned |
| Read all wallet balances | All balances returned |
| Read all open trading positions | Position data returned |
| Read full order and trade history | Complete history returned |
| Place spot orders | Accepted with no 2FA |
| Cancel all pending orders | Executed immediately |
Token lifetime was 30 days with no IP binding. Any party that could read the third party's web server logs (employees, infrastructure providers, CDN edge nodes, breach attackers) had a working session for the user. Multiplied across every customer who used the meme coin charts, staking screen, or Telegram login, this represents a continuous, silent leak of customer sessions into systems outside the exchange's security perimeter.
Remediation
- Check the URL host before injecting auth headers in the WebView wrapper. Only attach session headers to first-party domains
- For third-party WebView content, do not attach the exchange's authentication headers under any circumstance
- Audit every place the same wrapper is invoked and confirm none of the affected screens reach external domains
- Rotate the long-lived 30-day session token format. Move to scoped, short-lived tokens for sensitive operations and bind tokens to device fingerprints or IP ranges where possible
- Coordinate with the affected third parties to purge logs that may contain leaked tokens