Modern cryptocurrency wallets rely on strong cryptography to guarantee security, ownership, and trust. However, cryptography alone is insufficient when application-level controls fail. Recent LucidBit Labs vulnerability research of a mobile blockchain wallet revealed two independent severe vulnerabilities with serious implications: untrusted deep links could trigger sensitive wallet flows, and account deletion did not fully remove cryptographic private keys from the device.
While both issues were responsibly disclosed and ultimately fixed, together they expose a broader and recurring pattern in modern mobile crypto applications: strong cryptography paired with weak application-level security assumptions.
In 2026, users reasonably expect mobile cryptocurrency wallets to be resilient against known classes of failure that can lead to financial loss. The sector is increasingly regulated and subject to security audits, yet this review demonstrates that fundamental design mistakes can still bypass cryptographic guarantees and expose users to real-world risk.
When Trust Assumptions Break
Mobile blockchain payment apps promise users something deceptively simple: control.
- Control over funds.
- Control over identity.
- Control over when you leave.
When a user deletes an account, they expect their cryptographic footprint to disappear with it. When they open a wallet, they assume sensitive actions only occur through deliberate, authenticated user flows.
During a recent vulnerability research, we found that these assumptions did not fully hold. Instead, two separate vulnerabilities revealed a deeper issue, that is rooted not in blockchain design or cryptography, but at the intersection of mobile user experience, application logic, and security fundamentals.
These were not advanced exploits. They did not rely on zero-day vulnerabilities or kernel-level compromise. They relied on everyday user behavior and misplaced trust in mobile application boundaries.
Why This Matters to Users
Modern cryptocurrency wallets live on the same devices used for messaging, email, browsing, and social media. That reality fundamentally changes the threat model.
- Users click links.
- Users trust in-app navigation.
- Users assume deletion means exit.
When those assumptions fail, the resulting risk is not theoretical. It scales directly with adoption, usability, and trust in mobile platforms.
Vulnerability 1: Abusing Deep Links
This vulnerability was caused by an overly permissive deep link implementation that treated external URLs as trusted navigation events rather than untrusted input. By registering a wide-open custom scheme without strict route allow listing, parameter validation, or authentication gating, attackers could trigger internal wallet flows, inject malicious parameters, and initiate sensitive actions such as transaction signing via phishing links or malicious apps. As a result, the wallet became partially remote-controllable, allowing users to unknowingly approve malicious transactions through seemingly legitimate deep link interactions.
What are deep links?
Deep links are special URLs that open a specific screen or action inside a mobile app, instead of just launching the app’s home screen. They are what allow a link in an email, message, or website to take you directly to something like “approve transaction”, “reset password”, or “view wallet activity” inside an app.
They emerged with the rise of modern mobile operating systems as a way to improve user experience by reducing friction between apps and the web.
The problem is that deep links are also an attack surface. If not properly secured, they can:
- Be triggered by any external source (SMS, emails, browsers, ads)
- Bypass normal navigation or security checks
- Enable phishing, parameter injection, or unauthorized actions
Describing the Vulnerability
In a blockchain-based mobile payment application in a config.js file, we found the following scheme definition:
The problem is that by allowing the operating system to route any “myapp://” URI to the application process without restrictions can result in malicious input injection to specific pages and with minimal autorization to the application hidden transactions.
On both iOS and Android, custom schemes provide no cryptographic origin guarantees: any app, browser, QR code, or embedded WebView can invoke them. When combined with Expo Router’s automatic URL-to-route mapping, this effectively exposes internal navigation paths as remotely invocable entry points. Unless every deep-linked route enforces its own authorization and state validation, the scheme becomes an externally controlled interface into the app’s internal logic.
The vulnerability arises because deep links are treated as navigation events rather than untrusted inputs. Route parameters and query strings supplied via the URI are parsed and propagated into application state without a trust boundary, allowing attacker-controlled values to reach sensitive wallet flows.
In a security-sensitive application, this collapses multiple assumptions at once: that navigation only occurs through expected UI paths, that high-risk actions are reached only after explicit user intent, and that the app controls its own execution context.
Without strict route allowlisting, parameter validation, and mandatory authentication gating at the deep-link entry point, the custom scheme transforms the wallet into a partially remote-triggerable system driven by external input.
We found that the current implementation was vulnerable to:
- Malicious deep link attacks
- Parameter injection
- Unauthorized app triggering
Proof of Concept
We explain below about various exploit options and then a full possible attack scenario to exploit the application into transaction.
Launching arbitrary paths
We exploited the Deep Links vulnerability to launch various paths in the application for discovery and exploitation. We were able to fully obtain information, interact and exploit these pages (Onboarding, Import Legacy Data, Import Private Key, Signers, Contacts, etc).
Once we finished this stage we designed a controlled phishing simulation exercise that embedded attacker-supplied transaction parameters into an Android intent URI:
- We developed a controlled phishing simulation that closely resembled the application’s interface and presented users with a fictitious critical security update.
- We generated a transaction that, upon approval, would transfer funds to a controlled account used for testing.
- We merged the phishing page with the transaction details and created an intent URI triggered when a “Verify Identity and Secure your Wallet” button is clicked.
When sent to WhatsApp this can lead to the following sequence of events:
The tinyurl leads to the phishing page below, the victim is urged to press the verify your identity button.
This vulnerability is not limited to web links or phishing pages. The same transaction-triggering flow can be invoked directly at the operating system level.
On Android, for example, this can be achieved via the Android Debug Bridge (adb) or by any other application installed on the device that issues an explicit intent targeting the wallet.
As a result, a malicious Android application could programmatically trigger the signing flow without exploiting the OS. More sophisticated malware could wait for the user to legitimately open the app or trigger a transaction and then combine this behavior with an overlay or UI-manipulation technique to increase the likelihood of approving a malicious transaction.
A Full Exploitation Scenario
An exploit path to authorize pending transactions on wallets. Below you can see a structured sequence:
- An account has various transactions pending.
- An attacker discovers pending transactions and signers in the account.
- The attacker can craft a phishing page that triggers the transaction signing flow through a deep link when clicking a button.
- The attacker embeds the page in a link and sends it to the user's WhatsApp account.
- The user clicks the link, navigates to a page that displays a false message about “Account security” or shows fake transaction details.
- The user clicks the “Secure account now” button and is immediately prompted with a biometrics screen.
- The user confirms the biometric prompt, signing the pending transaction unknowingly.
We disclosed this vulnerability and the vendor who fixed the issue by preventing deep links from directly opening sensitive wallet screens, such as transaction signing, by redirecting any deep link to a protected route back to the app’s root. In addition, even if a user reaches a signing screen through navigation edge cases, the signing flow will not start automatically and now requires an explicit user action, ensuring transactions cannot be triggered silently via malicious links or intents.
Vulnerability 2: Cryptographic Key Persistence
This vulnerability stemmed from improper cryptographic key lifecycle management. The user removes the account but in fact he only deleted the UI reference, not the underlying signer private keys stored on the device. As a result, an attacker with later device access could re-import the account using its public address and regain full signing authority without re-entering keys, breaking user expectations and extending the impact of any device compromise.
What are Cryptographic keys?
Cryptographic keys are the true source of authority in wallet-based applications. While a public address merely identifies an account, the private key is what actually proves ownership and allows transactions to be signed.
The Discovered Vulnerability
The Remove Account feature removes the account from the device but does not delete the associated signer private keys from the key storage.
As a result:
- There is no cleanup mechanism to remove private keys from a device’s secure keychain.
- Private keys remain stored in the device's secure keychain.
- When reimporting the account, the singers with their original private keys are automatically available on the app.
- This creates false pretense to users, who think they've fully removed sensitive data from the device upon app deletion.
A Full Exploitation Scenario
- User removes his account from the mobile app.
- UI shows that the account was successfully removed. The private key, however, remains in the device's Keychain storage.
- An attacker gains access to a user’s device through:
- Physical access while the user is away
- Malware that gives remote access
- The attacker re-imports the account using its public address.
- Previously configured account signers are automatically available; re-importing private keys is not required.
Mitigations and Recommendations
The vulnerabilities described in this research stem from missing safeguards at the application layer, highlighting a broader issue in how mobile wallets are designed and secured. Addressing these risks requires treating mobile wallets as security-critical systems, not merely as user interfaces layered on top of strong cryptographic primitives.
In our research, the affected application was built using React Native and Expo, with a deep-link configuration that inadvertently granted access to all application screens. Other applications developed on the same technology stack may be exposed to similar weaknesses if deep-link handling and intent validation are not carefully designed and restricted.
As such, the following recommendations apply broadly to mobile cryptocurrency wallets and other high-risk financial applications built with comparable frameworks and configurations.
Treat Deep Links as Untrusted Input
- Deep links should be handled with the same level of skepticism as external network input.
- Sensitive screens (transaction signing, private key import, signer management etc) should never be directly reachable via deep links. Applications should explicitly restrict which routes can be invoked externally and redirect any attempt to access protected flows back to a safe entry point.
- Deep link handling should include strict parameter validation, sanitization, and mandatory authentication checks at the entry point. Navigation alone must not imply authorization, and no sensitive action should be initiated without clear, explicit user intent expressed through the application’s trusted UI.
- Where deep links are required, applications should consider allowing them only from a tightly controlled allowlist of trusted domains or package identifiers, rather than accepting invocation from any external source.
Enforce Explicit User Intent for High-Risk Actions
High-risk operations such as transaction signing, key import, or signer approval should never be triggered automatically as a result of navigation. Even when users legitimately reach these screens, the application must require an explicit, user-initiated confirmation step that cannot be satisfied by background processes, overlays, or external triggers. This ensures that sensitive actions are the result of conscious user decisions rather than coerced or deceptive flows.
Implement Proper Cryptographic Key Lifecycle Management
Account deletion must be treated as a cryptographic event, not just a UI operation. Removing an account should always include the secure deletion of all associated private keys, signer material, and secrets stored on the device. Any residual cryptographic material left behind extends risk beyond the user’s intent and undermines the core promise of self-custody.
Applications should provide clear and explicit controls for key removal and ensure that key destruction is irreversible, verifiable, and aligned with user expectations. This is especially critical in environments where devices may be lost, resold, shared, or later compromised.
Model the Mobile Threat Landscape Explicitly
Mobile wallets operate in hostile environments by default. Threat models should explicitly account for phishing links, malicious apps, operating system–level intents, overlays, and temporary physical access. Relying on platform defaults or assuming benign invocation paths is insufficient for applications that manage irreversible financial assets.
Security-critical mobile applications should define and document their lifecycle assumptions, trust boundaries, and entry points, and enforce them consistently across features and updates.
How LucidBit Labs Can Help
LucidBit Labs is a boutique cybersecurity research firm that goes beyond typical security assessments by combining offensive-grade expertise with practical engineering support.
We specialize in deep technical work, including security auditing complex systems, threat modeling, finding vulnerabilities, researching operating systems, reverse engineering and more.
We help our clients understanding real exploitability, prioritize risk, and implement fixes that fit into existing development workflows. With a focus on collaboration and delivering actionable results (not just reports), LucidBit is well suited for organizations building high-risk applications like crypto wallets, financial platforms, and other critical systems where security bugs can lead to real world losses.
Author Bios
Almog — Security Researcher
Almog brings over a decade of R&D experience and a track record of uncovering high‑impact vulnerabilities in high‑profile systems.
Assaf — Security Researcher
Assaf previously served as a researcher and technical writer in IBM Trusteer and Aqua Security research teams.