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.
At a glance
What this is: Veria Labs found that Kraken Wallet could let a malicious dApp appear verified and could render a transaction as a message signature, weakening user trust at both connection and signing stages.
Why it matters: For IAM and NHI practitioners, this is a reminder that trust signals are only useful when identity binding, intent separation, and approval context are enforced end to end.
Context
A dApp wallet flow is only as strong as the link between the origin being shown to the user and the action being signed. When those two layers drift apart, a malicious application can borrow trust from a legitimate identity and then redirect approval into a different operation.
This article sits at the intersection of digital identity, session trust, and transaction authorization. The issue is not just a wallet UX flaw, but a governance failure in how an application proves who it is and what the user is actually approving. The pattern is typical of phishing-adjacent wallet abuse, where visual trust cues outpace cryptographic intent checks.
Key questions
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. Once the trust label is spoofable, phishing becomes a session-level abuse problem rather than a simple branding issue. That is especially dangerous when the action being approved is irreversible.
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. If the application labels raw transaction bytes as a message, the user may approve an action that actually authorises value transfer. The risk is consent confusion, not broken mathematics.
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. The goal is to see whether a malicious dApp can change the verified identity, disguise executable bytes, or force the UI to present a higher-trust prompt than the payload deserves.
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.
Technical breakdown
How WalletConnect origin handling can be spoofed
WalletConnect sessions rely on metadata to present a dApp identity to the wallet and to the user. In this case, the verification path preferred a verified origin when present, but could fall back to the dApp-supplied metadata URL when the verified origin was missing. That means the safety check can be steered by attacker-controlled input if the verified identity record is absent or incomplete. The core weakness is not URL parsing alone. It is the assumption that a displayed origin and the real session authority are always bound together, when in fact the wallet may be trusting a label rather than an authenticated identity chain.
Practical implication: bind session safety decisions to a verified identity source, not to dApp-supplied metadata.
Why Solana message signing can mask transaction intent
The Solana signing path shown here decodes raw bytes and signs them directly, without strong domain separation between a human-readable message and an executable transaction payload. If a transaction instruction is encoded into a format the UI treats as a message, the user sees a benign signing prompt while the wallet actually authorises transaction bytes. That is an intent-confusion problem, not just a cryptographic one. Good signing design separates message signing, transaction signing, and contract interaction so the UI, parsing logic, and signature scope all agree on what is being approved.
Practical implication: enforce explicit domain separation between message signatures and transaction signatures.
Why the two flaws become a fund-theft chain
Either flaw on its own weakens trust, but together they create a complete abuse path. A spoofed dApp identity suppresses the warning state that should make a user hesitate, and the disguised payload then turns a transaction into a seemingly harmless signature prompt. The result is a consent bypass built from UI deception and signing ambiguity. This is the broader lesson for wallet and dApp ecosystems: user approval flows are security controls, and they fail when identity presentation and payload semantics are governed independently.
Practical implication: treat wallet approval UX as a security boundary and test the full user-to-signature path.
Threat narrative
Attacker objective: The attacker aims to obtain a legitimate user signature that authorises transfer activity while the wallet UI presents it as a harmless message approval.
- Entry occurs when the attacker presents a malicious dApp through WalletConnect with metadata that can impersonate a verified origin.
- Credential or approval abuse follows when the wallet accepts the spoofed trust signal and the user is steered into a seemingly safe session.
- Impact occurs when a transaction payload is disguised as a message signature, allowing the attacker to obtain user-authorised approval for fund theft.
Breaches seen in the wild
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
- Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Domain separation is the missing control concept here. A message signature and a transaction signature are not interchangeable, even if they share the same cryptographic primitive. The security boundary lives in the parsing, labelling, and policy decision that interprets raw bytes before the signature happens. Where that boundary is weak, attackers can convert routine approval flows into fund-transfer authorisation.
Non-human identity governance extends to wallet-connected applications. A dApp session is effectively an ephemeral identity relationship that must be verified, scoped, and constrained in real time. This is where NHI-style thinking matters: the application that is asking for trust needs an inventoryable, attributable identity, not just a display name. Teams should assume that identity presentation without intent binding creates a signing trust gap.
Kraken Wallet's issue illustrates a verification trust gap. The core failure is the gap between what the user is shown and what the wallet actually authorises. That gap is what phishing, impersonation, and consent manipulation exploit across digital identity systems. Practitioners should prioritise controls that collapse the gap between verified session identity and executable action.
Open source does not remove governance obligations. Public code can help scrutiny, but it does not guarantee that the trust model is robust under adversarial use. Security teams should assume that open implementation details make identity and signing mistakes easier to chain, not easier to dismiss. The practical conclusion is to test identity presentation and signing semantics together, not as separate reviews.
From our research library:
- Software supply chain attacks were projected to cost organisations $60 billion in 2025.
What this signals
Verification trust gap: when a wallet can present a trusted identity but still accept attacker-controlled action semantics, the control failure is architectural rather than cosmetic. That gap is what allows phishing-like consent manipulation to survive even when cryptography is technically sound.
For practitioners, the immediate question is whether session identity, signing intent, and UI labelling are governed by the same policy source. If those controls are separate, the user is being asked to resolve a security decision that the system itself has not resolved.
Wallet-connected applications should be treated as ephemeral non-human identities with a defined trust boundary. That means the operational problem is not only detecting abuse, but proving that the approval path cannot be repurposed from benign message acknowledgement into executable transaction consent.
For practitioners
- 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.
- Review mobile wallet trust labels for hidden fallback logic Inventory any code path where dApp-supplied metadata can override verified session context, then remove those fallbacks from security-sensitive decisions.
Key takeaways
- The article shows how a wallet can fail when identity verification and payload intent are governed separately.
- The chain works because a spoofed trusted dApp can suppress warnings while a transaction is rendered as a message signature.
- The control that matters is not stronger user caution but tighter binding between verified origin, signing mode, and approval semantics.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article shows a malicious dApp impersonating a verified origin in the wallet trust flow. |
| NHI-10 — Human Use of NHI | The wallet asks a human to trust a machine identity path that can be misleadingly presented. | |
| Recommendation — Enforce authenticated session identity for dApps and reject safety decisions based on self-asserted metadata. Separate human approval cues from machine-controlled dApp identity data before rendering consent. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The issue is fundamentally about trust in session-authenticating metadata and approval tokens. |
| Recommendation — Govern authenticator use so approval paths cannot be repurposed through weakly bound session data. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The attack succeeds when a user is led to authorise an action they did not intend. |
| Recommendation — Verify that authorisation prompts map to the actual action and entitlement being granted. | ||
| MITRE ATT&CK | TA0006;TA0004 — Credential Access; Privilege Escalation | The attack chain abuses user-approved signing to gain higher-value authorisation. |
| Recommendation — Map deceptive signing paths to credential access and privilege escalation detections. | ||
Key terms
- WalletConnect Session: A WalletConnect session is the temporary trust relationship between a wallet and a dApp that allows requests to flow between them. Security depends on the session being bound to the correct origin, methods, and chain context, not just on a successful pairing event.
- Domain Separation: Domain separation means a system keeps different kinds of signed actions distinct so one cannot be mistaken for another. In wallet security, it prevents a message signature from being treated as a transaction authorisation or any other higher-risk action.
- Verified Origin: A verified origin is the authenticated source identity a wallet uses to decide whether a dApp is trusted. If that identity can be bypassed, overwritten, or replaced with self-asserted metadata, the user may be shown a false trust signal at the approval step.
- Consent Confusion: Consent confusion occurs when a user is asked to approve one thing while the system actually performs another. In crypto wallets, this is especially dangerous because the human reviewer is expected to validate complex bytes, labels, and intent under time pressure.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners build stronger identity controls across session-based and delegated access models.
Published by the NHIMG editorial team on August 1, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org