WEB3-ADDRESS-POISONING-2024
Web3 · Wallets · Address poisoning / transaction-history spoofing
Summary
Address poisoning exploits the human habit of verifying only the first and last few characters of a wallet address; on May 3, 2024 a whale lost roughly $68M in WBTC after copying a poisoned look-alike address, the single largest recorded case. Attackers brute-force a vanity address whose leading and trailing characters match an address the victim recently transacted with, then seed it into the victim's history. They do this cheaply by emitting a Transfer event the victim did not authorize: a zero-value ERC-20 transferFrom, or a fake-token contract that emits Transfer logs, so the look-alike address appears in the wallet's recent-activity list at essentially gas-only cost (the $68M poisoning transaction carried 0 ETH value and about $0.65 gas). Later, the victim copies the recipient from their own transaction history, pastes the attacker's near-identical address, and sends funds directly to it. No signature exploit is involved; the attack is pure UI deception of the wallet's transaction-history display.
How to avoid it in your code
- Wallets must hide or clearly flag zero-value and unsolicited spam transfers and never surface unverified look-alike addresses as copyable history entries.
- Builders should display full addresses or middle-character checksums in send flows, not truncated forms that enable look-alike matching.
- Users must verify the entire destination address character-by-character, not just the prefix and suffix, before every send.
- Users should send from a saved address book or whitelist and never copy a recipient from raw transaction history.
- Wallets should support address labeling or a tiny test transfer so users confirm intended recipients.
References
Related vulnerabilities
All Web3 →- CRITICALWEB3-BLIND-SIGNING-2024
Blind signing, approving a payload the wallet cannot decode, is the final step behind the largest multisig drains: Radiant Capital lost about $50M in October 2024 and Bybit about $1.5B in February 2025, both via hardware-wallet signers approving transactions whose true effect their devices could not render. In the Radiant attack, malware showed legitimate-looking transaction data in the Gnosis Safe front-end while the hardware wallets actually received and signed a Safe execTransaction whose inner operation was a delegatecall to an attacker contract; that delegatecall executed in the Safe's own storage context and overwrote the implementation/owner state, handing control to the attacker. Because a hardware wallet's small display can only show a four-byte selector and raw hex, signers cannot parse a nested execTransaction or distinguish a benign call from a delegatecall that rewrites storage slot zero. The same root cause applies to legacy eth_sign, which signs an arbitrary 32-byte hash with no context, letting a phishing site obtain a signature reusable as a transaction authorization. The signer sees one intent and authorizes a different one.
- CRITICALWEB3-PERMIT-PHISHING-2024
Gasless permit signatures are now the dominant phishing vector: Scam Sniffer found Permit-type signatures accounted for 56.7% of 2024 wallet-drainer attacks within $494M of total losses, with cases like an October 13, 2024 Permit2 phish that drained roughly $1.39M of PEPE, MSTR and APU from one victim. EIP-2612 adds a permit(owner, spender, value, nonce, deadline, v, r, s) function so an owner signs an off-chain EIP-712 Permit struct that sets an ERC-20 allowance; the standard explicitly allows any address to submit it on-chain. The phishing dApp prompts that off-chain signature with the attacker as spender and value set to the full balance or type(uint256).max; the victim never sends a transaction or pays gas, and the wallet often shows an opaque typed-data blob. The attacker then submits permit() to register the allowance and immediately calls transferFrom to sweep the tokens. Uniswap's Permit2 generalizes this to every ERC-20: a single PermitSingle/PermitTransferFrom signature authorizes the attacker as spender, and because Permit2 defaults to the entire balance, one careless signature empties the wallet.
- HIGHWEB3-APPROVAL-PHISHING-2023
On-chain approval phishing remains a core drainer technique within the hundreds of millions stolen annually (Scam Sniffer attributed $295M in 2023 and $494M in 2024 to wallet drainers), abusing the standard ERC-20 approve and ERC-721/1155 setApprovalForAll authorization model. A malicious dApp prompts the victim to send a real on-chain transaction calling approve(spender, type(uint256).max) for a token, or setApprovalForAll(operator, true) (selector 0xa22cb465) for an NFT collection, designating the attacker contract as spender or operator. Wallets historically rendered these as a generic approve with no amount or as an unreadable contract interaction, so the victim confirms a high-value, broad authorization without understanding its scope. Once the allowance or operator flag is set, the attacker's contract calls transferFrom or safeTransferFrom at any later time to drain every token or NFT covered, with no further victim interaction. The approval persists indefinitely until revoked, so victims who signed months earlier remain exploitable.
- CRITICALWEB3-DRAINER-2024
Drainer-as-a-service kits (Inferno, Pink, Angel) industrialized crypto phishing, stealing roughly $295M from over 324,000 victims in 2023 and $494M from 332,000 victims in 2024 per Scam Sniffer; Inferno alone took nearly $88M from 137,000 victims before its November 2023 shutdown, with operators keeping a 20% cut of every theft and handing affiliates ready-made phishing scripts spoofing 100+ brands. The kit serves a malicious dApp front-end that injects a JavaScript drainer; it enumerates the connected wallet's most valuable tokens and NFTs, then sequences signature prompts whose intent the wallet cannot meaningfully render: an EIP-2612/Permit2 permit, an unlimited ERC-20 approve, or setApprovalForAll. Because the wallet shows an opaque EIP-712 hash or a generic approval, the victim clicks sign or confirm; the drainer relays the resulting signature or on-chain approval and immediately calls transferFrom or safeTransferFrom from a backend to sweep assets to attacker wallets, splitting proceeds with the kit operator. The affiliate model means thousands of low-skill actors run identical, optimized drainer logic at scale.
- HIGHWEB3-FRONTEND-DNS-HIJACK-2022
A frontend hijack leaves the on-chain contracts untouched but replaces the Web2 surface serving the dApp UI with a wallet-drainer clone, so no Solidity audit can catch it. The recurring pattern: attackers take over the domain registrar or DNS provider account (or a CDN/tag-manager account), repoint the domain to a cloned site, and prompt visitors to sign malicious token approvals, EIP-2612 permit signatures, or transfers. Curve Finance was hit twice: on August 9-10, 2022 its curve.fi domain was DNS-hijacked via a compromised nameserver and drained ~$570K in USDC/DAI; and again around May 12, 2025 at the registrar level, after which Curve permanently migrated to curve.finance and announced an ENS move (Convex Finance and Resupply, which depend on Curve's data feeds, suffered dependency-driven outages but were not themselves compromised). In July 2024 a mass wave hit DeFi domains registered through Squarespace, whose forced migration off Google Domains stripped 2FA: Compound's frontend redirected to an Inferno Drainer clone and 100+ protocols were exposed (Celer blocked its takeover via domain monitoring). Ambient Finance's domain was hijacked through stolen registrar credentials on October 17, 2024. Most recently, on April 14, 2026 attackers used forged identity documents to social-engineer the registrar into handing over DNS control of CoW Swap's swap.cow.fi and cow.fi domains, redirecting users to a pixel-perfect drainer clone for about 90 minutes; over $1M was taken in roughly three hours, including 219 ETH (~$750K) from a single wallet, while CoW's contracts, backend APIs, and solver network were untouched. The same bucket includes CDN-account injections (KyberSwap's September 2022 Cloudflare/Google Tag Manager compromise, ~$265K) and BGP route hijacks that swap signed bundles for drainer code.
- CRITICALWEB3-BUNNI-2025
On September 2, 2025 Bunni, a liquidity manager built on Uniswap v4, was drained of roughly $8.4 million across Ethereum and Unichain (USDC, USDT, and weETH/ETH) through a rounding error in its withdrawal accounting amplified by flash loans. Bunni's Liquidity Distribution Function (LDF) tracks an 'idle balance' that is rebalanced on every swap, and the withdraw path rounded that balance in the wrong direction under specific conditions. The attacker flash-borrowed millions in USDT and executed a precisely sized sequence of swaps that pushed the pool's spot price back and forth across tick boundaries, triggering the faulty rounding repeatedly; each cycle let them withdraw more tokens than they burned in liquidity (in the USDC/USDT pool the idle balance fell 85.7% while liquidity fell only 84.4%, and that gap was the leak). The bug was application-specific accounting math, not an oracle or price-feed flaw. Unable to fund a secure relaunch, the Bunni team announced on October 23, 2025 that it was permanently shutting down, leaving withdrawals open and relicensing v2 from BUSL to MIT.