Web3 application penetration testing for Wallet Connectors: Common Attack Paths

A compact, decision‑maker’s guide to penetration testing wallet connectors in modern web3 stacks. We break down concrete attack paths, show exactly what to test, and prescribe 2025‑ready controls that materially reduce drainer, phishing, and supply‑chain risk.

Why wallet connectors are today’s highest‑leverage pentest target

Wallet connectors sit at the trust boundary between your users and onchain execution. In 2024–2025, attackers shifted from contract exploits to front‑door theft via connectors: abusing over‑privileged sessions, deceptive signatures (Permit/Permit2), deep link hijacking, malicious mobile apps, and compromised UI libraries. Drainer kits alone siphoned roughly $494M in 2024 across 332k addresses, with toolkits like Angel Drainer/AngelX automating new vectors across EVM, TON, and Tron. If your security program benefits from one concentrated pentest, make it the connector surface. (drops.scamsniffer.io)

Also note: WalletConnect, the dominant connector network, rebranded its company to Reown and shipped a Verify API to bind wallet requests to the dapp’s real domain, enabling wallets to show “trusted/mismatch/threat” states directly in the signing UI. Your test plans should assume Verify exists and validate that your app is configured to pass it. (reown.com)

Attack path 1 — Supply‑chain compromise of connector libraries

The 14 Dec 2023 Ledger Connect Kit incident is the blueprint: a poisoned NPM/CDN build injected into many dapps, presenting malicious signing prompts that drained user funds until every site updated the library. This was a former employee’s npm account compromise leading to malicious releases (1.1.5–1.1.7), with ~$484k confirmed loss in hours. Pentests must treat connector packages and CDNs as hostile until proven otherwise. (ledger.com)

Practical tests

Bill of Materials reality check: Map every wallet connector or provider package (e.g., web3modal/AppKit, connect kits, injected-provider helpers, wagmi connectors), including “transitive” additions by bundlers. Flag any library loaded from a CDN at runtime (including lazy‑loaded chunks).
Integrity gates: Verify Subresource Integrity (SRI) on any third‑party script or self‑host and pin an exact version. Enforce a strict Content‑Security‑Policy (CSP) with nonce/hash + strict‑dynamic; forbid http/file sources; no inline event handlers. (w3.org)
Update and rollback drills: Simulate a compromised CDN by serving a mismatched SRI hash in staging; confirm the site fails closed and your fallbacks/logging catch it (SRI error telemetry + alert). (developer.mozilla.org)

Emerging best practices

Treat connector UI libraries like auth widgets: pin, verify, monitor, and rotate keys on maintainer turnover.
Use CSP nonces and SRI together; test with Report‑Only first to avoid breaking prod unexpectedly. (developer.mozilla.org)

Attack path 2 — Domain impersonation and deep‑link hijacking (WalletConnect, SIWE, mobile)

Two real‑world vectors dominate: a) phishing pages that mimic your brand and trick users into scanning a WalletConnect QR or clicking a “Connect” deep link, and b) malicious Android apps that register for “wc:” and intercept links.

What to verify in a pentest

WalletConnect Verify alignment: Ensure your dapp’s metadata.url matches the exact domain users see, and that wallets integrating Verify register your site as VALID (not UNKNOWN/INVALID/THREAT). Try domain mismatches (www vs apex, alternate environments) to force the wallet to show warnings. (docs.walletconnect.network)
SIWE domain binding: For any Sign‑In with Ethereum flows, confirm the signed message’s domain/uri/chainId/nonce semantics match the actual origin (and are enforced server‑side). Wallets must reject when the SIWE “domain” doesn’t match request origin; your relying party must bind sessions to the address and enforce nonce/expiry. (eips.ethereum.org)
Mobile deep links: On Android/iOS, test for deep‑link hijacking and incorrect redirects: scan QR on phone A, ensure app open/redirect only on intended wallet, and verify wallets ignore incomplete “wc:” URIs used solely for UX redirects. Validate Android App Links autoVerify, prevent hostile apps from claiming your link space, and confirm your wallet picker behavior when multiple apps register wc:. (developer.android.com)
Malicious apps: Validate your user communications discourage installing “WalletConnect” apps; recent fake apps on Google Play (e.g., “WallConnect”) stole user funds by impersonating the protocol. (bleepingcomputer.com)

Key spec details for test data

The WalletConnect v2 pairing URI includes a symmetric key (symKey) and permitted methods; ensure QR tampering or relay changes are detected and that expired pairing URIs fail after five minutes. (specs.walletconnect.com)

Attack path 3 — Over‑privileged sessions and dangerous JSON‑RPC methods

Wallet connectors negotiate capabilities. If your session proposal is overly broad, a compromised frontend can immediately request risky calls.

What to look for

Namespaces hygiene: Inspect the session proposal’s requiredNamespaces/optionalNamespaces. Minimize chains/methods/events; validate wallets refuse invalid CAIP‑2 chain IDs and empty lists. As a tester, fuzz namespaces (bad CAIP‑2, extra methods, wrong prefixes) and assert the wallet rejects with correct error codes. (specs.walletconnect.com)
Block dangerous methods: Ensure dapps never request deprecated or high‑risk methods like eth_sign. MetaMask no longer supports eth_sign; where absolutely unavoidable, it’s opt‑in behind an advanced toggle. Your connector should default to signTypedData_v4 or personal_sign. (docs.metamask.io)

Example: minimally‑scoped session for mainnet reads + SIWE

{
  "requiredNamespaces": {
    "eip155": {
      "methods": ["eth_call", "eth_signTypedData_v4", "personal_sign"],
      "chains": ["eip155:1"],
      "events": ["chainChanged", "accountsChanged"]
    }
  }
}

Fail case to catch in code review

{
  "requiredNamespaces": {
    "eip155": {
      "methods": ["eth_sendTransaction","eth_sign","eth_signTransaction","wallet_addEthereumChain"],
      "chains": ["eip155:1","eip155:10","eip155:42161","eip155:43114"],
      "events": ["*"]
    }
  }
}

Standards to anchor your checks

EIP‑1193 provider behavior (events, request) and error codes; ensure wallets rate‑limit and validate all data. (eips.ethereum.org)

Attack path 4 — Signature phishing (Permit/EIP‑712/Permit2) and “blind approval” drains

Drainers frequently bypass on‑chain approve prompts by presenting off‑chain EIP‑712 signatures (Permit/EIP‑2612 or Uniswap Permit2) that grant transfer rights, enabling fast multi‑asset drains. Numerous 2024–2025 losses trace to single Permit2 signatures. Pentests should simulate these signatures and validate your wallet UX, security extensions, and backend detections. (fullycrypto.com)

Pentest steps that surface real risk

Force Permit2 prompts with large allowances and long deadlines; confirm wallets render human‑readable summaries, warn on “unlimited approval,” and show deadlines in local time. Verify your UI never defaults to MAX_UINT. (letsdex.medium.com)
SIWE vs non‑SIWE: Ensure logins never piggyback EIP‑712 domains used for approvals; check your domain separator includes name, version, chainId, verifyingContract. (eips.ethereum.org)
Contract‑wallet signing: Validate ERC‑1271 paths for smart accounts and check your backend treats signature verification as chain‑specific. (eips.ethereum.org)

Incident patterns to cite in risk briefings

Single‑signature Permit2 drains of >$1.3M from PEPE holders (2024); multiple public write‑ups show the social‑engineering flow. (fullycrypto.com)
2024 phishing volume spikes correlating with airdrops and compromised social accounts; drainer kits rotate brands (Inferno→Angel). (theblock.co)

Mitigations to validate

Wallet‑side: Prefer eth_signTypedData_v4/personal_sign; render clear “who/what/to whom/amount/deadline”; alert on “unlimited” approvals.
Dapp‑side: cap allowances by exact need; short expiry; show token icons/decimals; call revoke helpers post‑flow; support EIP‑5267 to surface domain parameters to clients. (eips.ethereum.org)

Attack path 5 — Chain switching/addition and RPC tampering

When a dapp asks wallets to add or switch networks (EIP‑3085 / EIP‑3326), it’s easy to trick users onto a malicious RPC that misreports balances and routes approvals. Your connector should treat network prompts like auth prompts.

What to test and enforce

Require explicit confirmation on wallet_switchEthereumChain and wallet_addEthereumChain, showing requester origin and chain metadata; ensure wallets validate the chainId against eth_chainId on the supplied RPC URL and block non‑HTTPS/file schemes. (eips.ethereum.org)
Validate chain IDs against canonical registries (ethereum‑lists/chains.json); never allow duplicate chain IDs in the wallet. (github.com)
Replay‑safety: recheck that signing is bound to chainId, not to RPC‑reported values; EIP‑155/EIP‑695/EIP‑1344 should all line up. (eips.ethereum.org)

Attack path 6 — ERC‑4337 smart‑account flows through connectors (bundlers/paymasters)

Connectors increasingly expose account‑abstraction routes (eth_sendUserOperation). Misconfigured dapps let malicious UOs drain assets by swapping callData or paymaster terms, or by sending UOs to untrusted bundlers/paymasters.

Pentest actions

Verify your connector only speaks to allow‑listed bundlers/paymasters; simulate a “rogue bundler” endpoint and assert your app/wallet refuses or displays clear risk. (eips.ethereum.org)
Simulate sponsorship requests with extreme gas fee fields and unexpected paymaster post‑ops; ensure the wallet’s simulator flags hidden value transfers. (docs.erc4337.io)
If using WalletConnect’s Blockchain API for bundlers (e.g., Pimlico), validate projectId scoping per chain; block cross‑project reuse. (specs.walletconnect.com)

Evolving context: 4337 JSON‑RPC has consolidated in ERC‑7769; ensure your infra matches the finalized method shapes and that simulation/alerts support newer features (e.g., 7702 authorizations where enabled). (eips.ethereum.org)

Attack path 7 — Multi‑injected providers and extension spoofing

In browser land, multiple extensions race for window.ethereum. EIP‑6963 fixes discovery via event‑based multi‑provider announcements, reducing spoofing/override risk and enabling accurate wallet selection modals.

Pentest checks

Confirm your dapp implements EIP‑6963 discovery (or a modern library that does) and doesn’t silently bind to whichever extension “wins.” Exercise multiple installed wallets and confirm correct selection every time. (eips.ethereum.org)
Ensure branding drifts are handled: logos, IDs, and origins come from the provider info, not heuristic guesses. (eip.info)

Field‑tested pentest checklist (use this as your runbook)

Minimum‑viable tests that catch >80% of connector failures in the wild:

Verify/Origin binding

WalletConnect Verify: VALID on prod/stage; force INVALID and THREAT to see wallet warnings.
SIWE: reject if domain/uri/chainId don’t match origin; enforce nonce/expiry and bind sessions to wallet address. (docs.walletconnect.network)

Session capability minimization

Namespaces: request least‑privilege methods/events per chain; confirm wallet rejects CAIP‑2 errors and extra methods.
Block deprecated/opaque signing (eth_sign); prefer signTypedData_v4 or personal_sign. (specs.walletconnect.com)

Signature‑phishing defenses

Present EIP‑712/Permit2 scenarios with unlimited allowances and long deadlines; validate wallet UI warnings and your app’s allowance caps.
Test revocation flows and detect off‑chain Permit grants server‑side. (fullycrypto.com)

Network prompts and RPC integrity

wallet_addEthereumChain/wallet_switchEthereumChain require explicit user consent, show chain provenance, and pin RPCs. Validate chainId via eth_chainId and public registries; reject non‑HTTPS. (eips.ethereum.org)

4337 pathways

Allow‑list bundlers/paymasters; simulate malicious postOps; assert signing previews show net asset impact before approval. (eips.ethereum.org)

Deep linking and mobile

Android App Links with autoVerify; ensure no QR‑scan redirects open “wrong” apps; test multiple wallet apps on one device; reject incomplete wc: URIs for signing. (developer.android.com)

Supply‑chain guardrails

SRI + CSP strict‑dynamic on connector libraries; fail‑closed drills for CDN mismatches; avoid loading connect kits from mutable CDNs in prod. (developer.mozilla.org)

Run‑time threat simulation

Enable wallet‑side security alerts with transaction simulation (e.g., Blockaid in MetaMask); verify alerts across your key networks and measure false positives. (metamask.io)

Concrete examples (pass/fail with fixes)

Example A — WalletConnect Verify failing on staging

Symptom: Wallet shows UNKNOWN/INVALID for app.staging.example.com even though metadata.url is set to https://example.com.
Root cause: metadata.url mismatch and staging not allow‑listed in your project’s domain config.
Fix: Align app.metadata.url to the exact origin and add the staging domain. Rerun: wallet shows VALID; phishing banners disappear. (walletconnect.com)

Example B — Over‑privileged namespaces

Symptom: Your connect modal requests eth_sendTransaction on first connect (read‑only page).
Risk: A compromised frontend could immediately push a transaction request.
Fix: Split “connect‑only” vs “transact” sessions; upgrade scopes just‑in‑time when the user initiates a write. (specs.walletconnect.com)

Example C — Permit2 drain exposure

Symptom: Users can approve unlimited token spend via a single EIP‑712 signature; no deadline or UI summary.
Fix: Enforce capped allowance, require short deadlines, and show human‑readable previews for typed data; warn on unlimited. Cross‑verify with wallet alerts and simulate revocation UX. (fullycrypto.com)

Example D — Chain switching to unverified RPC

Symptom: Dapp proposes a new chain with a third‑party RPC; wallet doesn’t verify chainId consistency.
Fix: Wallet must fetch eth_chainId from proposed RPC and compare to requested chainId; reject if mismatch; dapp must prefer known chain registries. (eips.ethereum.org)

2025‑ready control set you can standardize

Adopt these as acceptance criteria for every release that touches “Connect Wallet”:

Domain binding by default
- WalletConnect Verify integrated; SIWE strictly enforces domain/uri/nonce/expiry; sessions bound to address. (docs.walletconnect.network)
Capability‑minimized sessions
- Separate read vs write sessions; never request eth_sign; log and alert on unexpected method requests. (docs.metamask.io)
Human‑readable signing and simulation
- Always show chain, contract, token, amount, deadline; enable wallet‑side simulation/alerts across supported chains (MetaMask+Blockaid et al.). (support.metamask.io)
Network prompt hardening
- Require explicit user confirmation on add/switch; validate chainId via eth_chainId and public registries; pin RPCs; no http/file schemes. (eips.ethereum.org)
SRI + strict CSP on connector code
- Self‑host critical JS; pin versions; monitor SRI failures; keep fallbacks and report‑only CSP to iterate safely. (developer.mozilla.org)
Mobile linking safety
- Android App Links autoVerify; reject incomplete wc: URIs; test multiple wallets on one device; document official wallet apps and warn against “WalletConnect” impostors. (developer.android.com)
4337 hygiene
- Only trusted bundlers/paymasters; surface EIP‑712 userOp hashes in previews; audit postOps flows; update to ERC‑7769 RPC shapes. (eips.ethereum.org)
Multi‑wallet discovery
- Implement EIP‑6963; never assume window.ethereum is “the” wallet. (eips.ethereum.org)

Brief in‑depth: how to fuzz WalletConnect sessions like an attacker

Use a gray‑box approach against your dapp in staging with a controlled wallet:

Namespace fuzzing

Send proposals with: empty chains; non‑CAIP‑2 IDs; banned methods (eth_sign); excessive chains. Expect rejections with specific codes (e.g., 5100/5001), and validate your client aborts connect on mismatch. (specs.walletconnect.com)

Pairing URI tampering

Modify symKey, relay‑protocol, and expiryTimestamp in the wc: URI. Ensure the wallet rejects and the pairing expires in ~5 minutes if inactive; active pairings rotate expiry on use. (specs.walletconnect.com)

Verify negative tests

Host a look‑alike domain; confirm wallets show THREAT/INVALID and block or hard‑warn. (docs.walletconnect.network)

4337 endpoints

Point the connector to a non‑allow‑listed bundler; assert failure before signing. (eips.ethereum.org)

Executive wrap‑up

The connector layer is where modern web3 risk concentrates. The highest‑ROI fixes aren’t exotic: bind origin, least‑privilege sessions, human‑readable/typed signatures, simulation‑backed warnings, verified networks/RPCs, and hardened frontends (SRI+CSP) against supply‑chain shenanigans. Implementing WalletConnect Verify, SIWE domain checks, EIP‑6963 discovery, ERC‑7769‑aware 4337 flows, and MetaMask‑style security alerts gives measurable risk reduction against phishing and drainers that target wallet connections directly. (docs.walletconnect.network)

References called out in this guide (selected)

Reown/WalletConnect Verify API and rebrand updates (2025). (reown.com)
Ledger Connect Kit incident and coordinated mitigation (Dec 2023). (ledger.com)
ScamSniffer phishing/drainer telemetry (2024). (drops.scamsniffer.io)
MetaMask deprecations and safe signing guidance. (docs.metamask.io)
Session namespaces, pairing URIs, and lifecycle in WalletConnect v2. (specs.walletconnect.com)
SIWE (EIP‑4361) domain binding. (eips.ethereum.org)
EIP‑3085/3326 chain add/switch security considerations; chain registries. (eips.ethereum.org)
ERC‑7769 / ERC‑4337 JSON‑RPC (eth_sendUserOperation). (eips.ethereum.org)
EIP‑6963 multi‑wallet discovery. (eips.ethereum.org)
SRI and CSP strict‑dynamic implementation. (developer.mozilla.org)

Description: A practical, up‑to‑date playbook for penetration testing wallet connectors in web3 apps, focused on the real attack paths seen in 2024–2025 and the concrete controls that stop them. Includes test cases for Verify/SIWE domain binding, namespaces minimization, Permit2 drains, chain add/switch abuse, 4337 flows, deep links, and supply‑chain hardening.