Kraken Wallet dApp impersonation shows how signing trust breaks

At a glance

What this is: Veria Labs found that Kraken Wallet could be tricked into trusting a spoofed dApp and into displaying a transaction-signing request as a message-signing prompt.

Why it matters: This matters because wallet authentication, signing flows, and identity assurance are the control boundary that prevents human approval from being converted into unauthorised crypto transfers.

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.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.

👉 Read VERIA LABS' analysis of Kraken Wallet dApp impersonation and Solana signing risk

Context

Kraken Wallet’s issue is not simply a UI flaw. It is an identity assurance problem in a signing workflow, where the application trusts metadata from the dApp and then asks a human to approve a cryptographic action that may not be presented with the right context. In practice, that weakens the boundary between authentication, authorisation, and user intent.

For IAM and NHI practitioners, the parallel is clear: when a system accepts external claims about identity or intent without strong binding, attackers can exploit the gap even if the underlying cryptography remains intact. That is why wallet flows, OAuth-style delegation, and machine-to-machine approval paths all need explicit trust boundaries, not just secure transport. The starting position here is unfortunately typical for fast-moving application ecosystems.

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 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. If encoded payloads can be rendered as a message prompt, a user may approve a transfer without realising it. The issue is not just signing, but whether the prompt accurately reflects the effect of the signature.

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. Security testing should include payload disguises and malicious metadata, because the control gap is usually in presentation and trust binding, not in the signature algorithm itself.

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.

Technical breakdown

Verified dApp impersonation in WalletConnect flows

WalletConnect-style pairing depends on metadata that describes the requesting application, including its origin and safety context. In this case, the wallet preferred a verified origin when present, but fell back to the dApp-supplied metadata URL when that field was absent. That creates a trust ambiguity: the wallet is effectively delegating part of its safety decision to untrusted input. If the safety check is only as good as the dApp can make it appear, then the trust signal becomes spoofable rather than authoritative.

Practical implication: bind trust decisions to independently verifiable origin data, not dApp-provided metadata.

Why message signing without domain separation is dangerous

A message-signing function should make it obvious what is being signed and why. Here, the Solana path decoded the supplied bytes and signed them directly, without a strong separation between a human-readable message and a transaction payload. That means a crafted transaction can be encoded so the wallet presents a benign-looking message prompt while the underlying bytes still authorise a transfer. The cryptographic signature is valid, but the user’s mental model is not aligned with the actual action.

Practical implication: enforce domain separation and explicit transaction-type rendering before any signature is requested.

Chaining identity trust with signing intent

The exploit chain works because two weak assumptions reinforce each other. First, the user is led to trust a spoofed dApp identity. Second, the request is rendered in a way that hides the true transaction semantics. This is a classic assurance failure: the approval step is not backed by enough context for the human to make a safe decision. In identity terms, the system has authenticated a session but has not adequately authorised the specific action being approved.

Practical implication: treat dApp identity, session trust, and transaction intent as separate controls that all must pass.

Threat narrative

Attacker objective: The attacker’s objective is to get the wallet owner to authorise a malicious Solana transfer while believing they are only signing a message.

1. Entry occurs when a malicious dApp pairs through WalletConnect and supplies metadata that can masquerade as a verified origin.
2. Credential access is replaced here by approval abuse: the wallet session gives the attacker a trusted channel to request a signature from the user.
3. Impact occurs when the signed payload authorises a transfer while the interface presents it as a harmless message signature, enabling fund theft.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Intent binding is the named control gap this exploit exposes. The wallet authenticated a session, but it did not bind the requested action tightly enough to a specific, human-verifiable transaction type. That is the same structural weakness seen in other delegation failures, where a legitimate session is abused to perform an illegitimate action. NIST SP 800-63 Digital Identity Guidelines and NIST SP 800-53 Rev 5 Security and Privacy Controls both point toward stronger assurance and access control separation. Practitioners should require explicit intent binding for every high-risk signing flow.

Non-human identity thinking applies to wallets, dApps, and approval channels. A dApp is not a human user, but it still needs its own trust posture, lifecycle, and verification boundaries. Where an application can impersonate another application’s identity, the organisation has effectively lost control over delegated trust. That is why identity programmes should extend beyond login to the approval surface itself. Practitioners should map wallet and dApp trust to the same governance discipline used for privileged service identities.

Attack chains that look minor in isolation often become material when they cross trust layers. A spoofed origin and a misleading signature prompt may each seem survivable on their own, but together they convert a user click into irreversible asset movement. This is the kind of composite failure that security reviews frequently miss when they assess controls one layer at a time. Practitioners should review adjacent control failures, not isolated bugs.

Kraken Wallet’s case shows why open source does not eliminate assurance risk. Public code can improve scrutiny, but it does not guarantee that every trust decision is implemented with the right verification boundary. Security teams still need to inspect how session identity, metadata trust, and action rendering are connected. Practitioners should prioritise control review at the points where identity claims become irreversible actions.

From our research:

• 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.
• From our research: 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.
• Forward look: The Ultimate Guide to NHIs helps teams classify non-human identities before they become an approval or access problem.

What this signals

Intent binding: wallet approval flows should be treated as privileged decision points, not cosmetic user experience. Once a prompt can misrepresent the action being authorised, the organisation has a governance problem that reaches beyond appsec into identity assurance and transaction risk.

The broader signal for practitioners is that delegated trust is only as strong as the weakest representation layer. Teams should review whether their approval paths, signing prompts, and origin checks can be independently verified, especially where user consent can trigger irreversible value movement. NIST SP 800-63 Digital Identity Guidelines is relevant whenever assurance depends on a human making a high-risk decision.

For identity and security programmes, this is a reminder that non-human identities are not only about service accounts and API keys. Any software entity that can initiate, shape, or request an approval deserves lifecycle controls, bounded trust, and auditability. The control question is whether the system can prove what it is asking the user to approve before the user approves it.

For practitioners

• 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. The safest pattern is to treat dApp-supplied URLs as hints, not as trust anchors.
• 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. Add explicit type labels and transaction summaries before any signature prompt appears.
• Review approval surfaces as identity controls Audit wallet prompts, signing flows, and session permissions as part of identity governance, not just appsec. Where a prompt can trigger irreversible asset movement, the interface must be governed like a privileged access path.
• Test adversarial payload disguises Include base58, base64, and other encoding variants in security testing so attackers cannot hide transaction bytes inside apparently harmless message requests. Validate that the UI always reflects the true action semantics before approval.

Key takeaways

• The breach pattern is an assurance failure, because a spoofed dApp identity and misleading signing prompt can turn a valid cryptographic signature into an unauthorised transfer.
• The impact is material even when individual flaws look small, because chained trust failures can convert a routine wallet approval into irreversible asset loss.
• The preventive control is intent binding, meaning the wallet must verify origin, label request type clearly, and fail closed whenever it cannot prove the action being approved.

Key terms

• Intent Binding: Intent binding is the control property that keeps an action attached to the approved business purpose that authorised it. For AI agents, that means the request path, session context, and audit record must all point back to the same governed transaction, or accountability collapses.
• Message Signing: Message signing is the process of producing a cryptographic signature over data that is not necessarily a transaction. The control risk arises when a wallet or application fails to distinguish a harmless message from an instruction that can move assets or change state. Clear rendering and domain separation are essential.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

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

👉 The full VERIA LABS post covers the exploit chain, proof-of-concept code, and remediation timeline.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives practitioners the governance vocabulary to handle delegated trust, approval flows, and identity lifecycle controls across modern environments.