Telegram Mini App Research Makes Local Storage A Wallet Boundary

An August 18 preprint presents TENET, a scanner built to inspect Telegram Mini App data stored in desktop WebView databases. The researchers screened 61 popular cryptocurrency and wallet Mini Apps and successfully analyzed 37. After manual validation, they reported security-relevant local data in 30: replayable session material, wallet secrets or private keys, mnemonic recovery phrases, or ciphertext whose recovery material was stored beside it. The sample was popularity-weighted and deliberately oversampled financial apps, so 30 of 37 is not an ecosystem-wide prevalence estimate.

The study is about embedded web-app storage, not a break in Telegram's MTProto messaging protocol. Its main desktop threat model requires malicious code already running with the user's privileges, while a separate proof of concept uses cross-site scripting inside a vulnerable Mini App to read that app origin's storage. Telegram added SecureStorage and DeviceStorage APIs after disclosure, and the researchers confirmed that the official Wallet no longer exposed its recovery mnemonic through the tested local-storage path. They did not verify remediation across every third-party app, so developers and users still need app-specific evidence.

TENET is a purpose-built scanner for the LevelDB and SQLite storage used by Telegram Mini Apps on desktop systems. It applies 27 detection patterns, character-set checks, and entropy thresholds to candidate values. On a separately annotated 500-entry evaluation set, the authors report 94.3 percent precision, 96.7 percent recall, and a 95.5 percent F1 score. They then manually filtered false positives in the main measurement before classifying findings.

The sample needs equal attention. The researchers started from a community directory, selected popular apps across categories, and oversampled Web3 and wallet software because of its financial exposure. Of 61 candidates, 37 could be analyzed: 28 cryptocurrency-related Mini Apps and nine wallets. Apps that failed to run, were mobile-only, lacked the relevant functionality, or redirected to another wallet were excluded. This is useful evidence about a high-risk slice, not a random survey of Telegram's full Mini App population.

The reported audience figure is also easy to misread. The affected apps represented more than 53 million aggregate monthly-active counts in the paper's source data, but one person can use several apps and some counts were unavailable. The authors explicitly warn that the sum is not a unique-user total. No user database was breached for the study; testing used dedicated research accounts and locally generated data.

Mini Apps are web applications rendered inside Telegram's embedded WebView. Their backends and storage sit on a channel separate from Telegram's core messaging traffic. Conventional localStorage, IndexedDB, cookies, and session storage can therefore hold application state on the device. Telegram's chat protocol can remain intact while a third-party Mini App puts a bearer token or recovery phrase in a database readable to the logged-in operating-system user.

The primary desktop extraction path assumes local user-space access. That is a meaningful prerequisite, not a remote zero-click claim. It is also realistic after phishing, a malicious document, remote-access abuse, or an infostealer infection. Microsoft has documented commodity malware that reads browser credentials, clipboard data, and cryptocurrency-wallet material. Once malware runs as the user, an unencrypted WebView database offers the same kind of harvestable target.

The paper demonstrates a second, narrower route. If a Mini App contains an XSS flaw, attacker-controlled script running in that app's origin can read secrets stored for the same origin and send them away. It cannot automatically read every other Mini App's origin. OWASP has long advised against placing session identifiers or sensitive information in localStorage because local privileges and one origin-level XSS can defeat the assumed confidentiality.

The authors assign each affected app to its highest applicable tier. Tier 1 is plaintext storage of a mnemonic phrase or private key. A copied recovery phrase can recreate a self-custodial wallet elsewhere, so the impact is not limited to one Telegram session or device. Wallet's own guidance says the phrase grants full access and cannot be changed; suspected exposure requires creating a new wallet and transferring assets rather than merely changing an account password.

Tier 2 is encrypted data stored with enough recovery material to undo the protection. The study found examples where a key, salt, iteration count, or hardcoded JavaScript value sat beside the ciphertext. Encryption does not create an independent boundary when the same process and storage location provide both the locked box and the key. A developer should use an operating-system-backed key or require a secret that is never persisted with the data.

Tier 3 is a plaintext JWT, session token, or equivalent bearer artifact. The researchers manually verified the explicit JWT examples against the corresponding backend APIs and found them replayable, sometimes for sensitive queries. Token theft can be contained with short lifetime, narrow scope, server-side revocation, rotation, and anomaly detection. Those controls do not help a non-rotatable mnemonic, which is why the article's response distinguishes session containment from wallet migration.

Telegram documents SecureStorage and DeviceStorage as separate APIs. SecureStorage associates values with the logged-in user and Mini App, uses the system Keychain on iOS and Keystore on Android, and is intended for tokens, secrets, and authentication state. Telegram limits a bot to ten secure items per user. DeviceStorage is persistent structured storage, but the documentation does not present it as protection for secret material.

The paper says Telegram introduced both APIs during the coordinated-disclosure window. Telegram's public Mini App change log dates their addition to Bot API 9.0 on April 11, 2025. The authors later retested the official Wallet and found that its recovery mnemonic had moved from recoverable plaintext into an encrypted form their local extraction no longer recovered. That is direct remediation evidence for the tested Wallet build and technique.

It is not a platform-wide clearance. A third-party developer must migrate existing values, clear unsafe copies, update supported clients, revoke old tokens, and prove that fallback paths do not repopulate web storage. The paper says affected developers were notified, but it does not publish a current verified status for every app. SecureStorage also does not repair XSS, unsafe backend authorization, or an already compromised endpoint. It reduces at-rest extraction risk at one layer.

Update Telegram and each wallet or Mini App through trusted channels, then remove apps no longer used. Users of the official Wallet can rely on the paper's post-fix test for the specific local-storage exposure, but should still follow Wallet's own recovery guidance and protect the Telegram account and endpoint. The research does not say every Wallet user needs to move funds, and an old finding by itself is not proof that a particular phrase left the device.

Escalate when there is a concrete signal: known malware on the desktop, an alert for infostealer behavior, an unexplained Telegram session, unauthorized wallet activity, a developer notice, execution of suspicious files, or evidence that a vulnerable app stored the user's recovery material. Revoke active sessions and application tokens where possible, reset credentials reachable from the host, and investigate the endpoint. If a self-custodial recovery phrase may have been exposed, create a new wallet from a clean device and transfer assets according to the wallet provider's verified process.

Enterprise teams should inventory Telegram Desktop and financial Mini App use on managed endpoints rather than extracting employees' wallet data without authority. Apply endpoint controls, browser and WebView telemetry, application allowlisting, and incident playbooks for token and wallet theft. Where financial Mini Apps are not an approved business requirement, policy can separate them from devices holding source code, administrator sessions, production credentials, or sensitive communications.

Do not store mnemonic phrases, private keys, refresh tokens, or long-lived session identifiers in localStorage or IndexedDB. Prefer a design in which a native wallet signs a transaction without returning the seed to the Mini App. When a local secret is unavoidable, use SecureStorage on supported clients, define a safe unsupported-client path, and keep non-sensitive preferences in DeviceStorage. Delete legacy copies only after migration has been tested.

Treat tokens as disposable. Use short expiration, audience and scope restrictions, rotation on use where practical, backend revocation, device or session binding, and visible session management. Telegram's Mini App documentation also requires server-side validation of initData rather than trusting initDataUnsafe. Check the signature and freshness before using Telegram identity fields, and never turn a client-provided identifier into wallet or account authority without server-side authorization.

Finally, make the active web origin hostile by assumption. Enforce a restrictive Content Security Policy, encode output, remove dangerous script sinks, isolate untrusted content, review dependencies, and test XSS against every route that can access secrets. Log sensitive storage operations without logging the value, add regression tests that fail when secrets enter web storage, and publish a clear security contact and remediation status. A secure API helps only when the application actually uses it and the surrounding session design can recover from theft.