Notifications
Clear all
Topic starter
01/08/2026 8:59 pm
TL;DR: Kraken Wallet’s WalletConnect flow can let a malicious dApp impersonate a verified one, while Solana payload handling can present a transaction as a message signature, creating a path to user-authorised fund theft, according to Veria Labs. The case shows how trust signalling and message domain separation fail when wallet UX and signing logic are not tightly bound to transaction intent.
NHIMG editorial — based on content published by VERIA LABS covering Kraken Wallet signing risk: Securing Open Source Cracking Kraken krakenfx/ wallet
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: What breaks when a wallet trusts dApp metadata too much?
A: The wallet can be tricked into treating an untrusted application as verified, which undermines the user’s ability to judge whether a signing request is legitimate.
Q: Why do message signing flows create approval risk for crypto wallets?
A: Message signing becomes risky when the UI does not clearly separate harmless text from executable transaction data.
Q: How should security teams reduce spoofing risk in wallet approval flows?
A: They should bind approval prompts to independently verified origin data, classify the request type unambiguously, and fail closed when the application cannot prove the request came from a trusted context.
Practitioner guidance
- Harden dApp origin validation Require wallet and dApp implementations to verify origin data independently, and block fallback to untrusted metadata when a verified origin is missing.
- Separate message and transaction signing Render Solana and other chain-specific signing requests with strict domain separation so a transaction payload cannot be presented as a generic message.
- Review approval surfaces as identity controls Audit wallet prompts, signing flows, and session permissions as part of identity governance, not just appsec.
What's in the full article
VERIA LABS' full post covers the operational detail this analysis intentionally leaves for the source:
- Step-by-step proof-of-concept logic for the WalletConnect pairing and Solana signing chain
- Code-level analysis of how verified origin fallback and metadata URL selection interact
- The exact payload encoding variants used to disguise a transaction as a message request
- The remediation timeline and the vendor’s response to the reported vulnerability
👉 Read VERIA LABS' analysis of Kraken Wallet dApp impersonation and Solana signing risk →
Kraken Wallet signing risk: what happens when dApps can spoof trust?
Explore further
01/08/2026 9:06 pm
Wallet signing risk is increasingly an identity assurance problem, not just an application bug. The important failure here is not the cryptographic primitive itself, but the mismatch between what the wallet thinks it is authorising and what the user thinks they are approving. Once a dApp can influence the safety label or the prompt wording, the trust model is compromised. Practitioners should treat signing UX as part of the identity control plane.
A few things that frame the scale:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys, according to DeepSeek breach.
A question worth separating out:
Q: Who is accountable when a malicious dApp causes an unauthorised transfer?
A: Accountability sits across the wallet provider, the dApp developer, and the organisation operating the wallet trust model. If the approval flow allows spoofed identity signals or ambiguous signing prompts, then control ownership is incomplete. NIST SP 800-53 Security and Privacy Controls and NIST SP 800-63 Digital Identity Guidelines are relevant for defining assurance and access governance expectations.
👉 Read our full editorial: Kraken Wallet dApp impersonation shows how signing trust breaks
