Topic starter
01/08/2026 8:59 pm
TL;DR: A malicious dApp could impersonate a verified one in Kraken Wallet, Veria Labs found, while Solana payload handling could present a transaction as a message signature. Wallet approval depends on tighter binding between verified origin, signing mode and intent.
Editorial analysis by NHI Mgmt Group, based on content published by Veria Labs: “Securing Open Source Part 2: Cracking Kraken”.
Key questions
Q: Why do message signing bugs create transaction theft risk in wallet apps?
A: Because message signing and transaction signing can share the same low-level cryptography while carrying very different security meaning.
Q: How should teams test for signing trust gaps in dApp wallets?
A: They should test the full approval chain, from session identity to payload labelling to final signature output.
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.
Practitioner guidance
- Harden dApp origin verification Require verified, non-fallback identity sources for WalletConnect session safety decisions, and fail closed when the verified origin is absent or ambiguous.
- Separate message and transaction signing paths Make the wallet UI, parsing layer, and policy engine distinguish message signatures from transaction signatures before any approval is rendered.
- Test consent confusion with malicious dApp simulations Use red-team scenarios that swap verified metadata, encode transaction bytes as messages, and measure whether the approval flow still exposes the real intent.
Bottom line: The article shows how a wallet can fail when identity verification and payload intent are governed separately.
Glossary terms: WalletConnect Session, Domain Separation, Verified Origin, Consent Confusion
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 8 hours ago by NHI Mgmt Group
01/08/2026 9:06 pm
Signing trust is a governance problem, not just a UI problem. When a wallet can display a benign identity and a benign action label for something materially different, the control plane has failed at the point of user consent. That means the security model is not enforcing a single, authoritative binding between verified origin, session identity, and payload intent. Practitioners should treat approval screens as enforceable controls, not cosmetic context.
A few things that frame the scale:
- Software supply chain attacks were projected to cost organisations $60 billion in 2025.
A question worth separating out:
Q: When should mobile wallet teams treat approval UX as a security control?
A: Always, but especially when the product supports third-party dApps, WalletConnect-style sessions, or multiple signing modes. In those environments, the approval screen is the last control before authorisation, so its labels, warnings, and identity cues must be enforced with the same rigor as backend policy.
👉 Read our full editorial: Kraken Wallet dApp impersonation shows how signing trust breaks