WEB3-SIG-REPLAY-2022
Web3 · Ethereum · ECDSA signature verification (EIP-155 / EIP-712)
Summary
Signature replay occurs when a signed message lacks binding context (nonce, chainId, or an EIP-712 domain separator), so a signature valid for one execution can be re-submitted on another call or another EVM chain. The canonical 2022 case is the Optimism/Wintermute loss of 20,000,000 OP tokens disclosed June 9, 2022: Wintermute provided a Gnosis Safe address deployed on Ethereum mainnet but not on Optimism. Because the Gnosis Safe factory's original deployment transaction used a pre-EIP-155 signature, its hash covered only six RLP fields (nonce, gasPrice, gas, to, value, data) and omitted chainId, so anyone could rebroadcast the identical signed transaction on Optimism. An attacker replayed that deployment to recreate the factory and Safe at the same counterfactual address on L2, gained control of the contract account before the rightful owners, and swept the 20M OP. The same low-level flaw appears in application contracts that ecrecover a digest missing nonce/chainId, letting one signed approval be replayed repeatedly.
How to avoid it in your code
- Hash chainId, a per-account incrementing nonce, and the verifying contract address into every signed digest.
- Use EIP-712 typed-data hashing with a full domain separator (name, version, chainId, verifyingContract).
- Mark each signature consumed (a mapping of used digests) to block same-chain replay.
- Recompute the domain separator if block.chainid changes to survive forks.
- Reject malleable or non-EIP-155 signatures and constrain the signature's v value to canonical values.
References
- https://slowmist.medium.com/slowmist-key-to-the-theft-of-20-million-op-tokens-transaction-replay-490baaf45f26
- https://inspexco.medium.com/how-20-million-op-was-stolen-from-the-multisig-wallet-not-yet-owned-by-wintermute-3f6c75db740a
- https://cryptobriefing.com/wintermute-makes-optimistic-assumption-loses-20m-optimism-tokens/
Related vulnerabilities
All Web3 →- CRITICALWEB3-DRIFT-2026
On 1 April 2026, attackers drained about $285 million from Drift, the largest perpetual-futures exchange on Solana, in roughly twelve minutes, more than half of everything the protocol held. There was no smart-contract bug. The contracts worked exactly as written. The attackers, later tied to North Korea's Lazarus operations, spent months socially engineering the people with privileged access, then abused a Solana feature called durable nonces to get the protocol's multisig signers to approve, in advance and without realising it, the transactions that handed over control. Once they had admin rights they whitelisted a worthless token as collateral, deposited a pile of it, and borrowed out the real money. It is the case that proves the modern crypto heist is an operations and social-engineering problem, not a Solidity one.
- 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.
- CRITICALWEB3-WAZIRX-2024
On July 18, 2024 Indian exchange WazirX lost approximately $230M (about $234.9M) from a Safe (Gnosis) 4-of-6 multisig wallet held under a custody arrangement with Liminal (five WazirX keys plus one Liminal key). The attack was a blind-signing exploit: signers reviewed benign transaction details in the manipulated Liminal interface while the payload actually signed differed, authorizing a delegatecall (function selector 0x804e1f0a) that overwrote slot0 of the Safe proxy and repointed its implementation to an attacker-controlled contract (0xef279c2ab14960aa319008cbea384b9f8ac35fc6). Once the proxy pointed to attacker logic the wallet was fully controlled without further keys, and it was drained. The theft was attributed to North Korea's Lazarus Group, later confirmed in a joint statement by the US, South Korea and Japan in January 2025. Funds were laundered via Tornado Cash; victims are being repaid through a court-approved restructuring (resumed October 2025, BitGo custody) rather than direct recovery.
- CRITICALWEB3-DMM-BITCOIN-2024
On May 31, 2024 Japanese exchange DMM Bitcoin lost 4,502.9 BTC, worth approximately $305M-$308M at the time. The compromise was a supply-chain social-engineering chain that did not breach DMM directly: a TraderTraitor operator posing as a recruiter on LinkedIn sent an employee of wallet-software vendor Ginco a malicious Python script disguised as a GitHub pre-employment coding test. The malware (RN Loader / RN Stealer) harvested SSH keys, credentials and cloud configurations; weeks later attackers used stolen session cookies to impersonate the Ginco employee, access the unencrypted communications system linked to DMM, and tamper with a legitimate withdrawal request submitted by a DMM employee, redirecting 4,502.9 BTC to attacker addresses. US and Japanese authorities (FBI, DC3, Japan's NPA) attributed the theft to North Korean actors tracked as TraderTraitor (Jade Sleet / UNC4899), associated with the Lazarus Group. Funds were not recovered; DMM Bitcoin shut down and transferred accounts to SBI VC Trade.
- CRITICALWEB3-BNB-CHAIN-2022
On October 6, 2022, an attacker forged a Merkle proof against the BSC Token Hub, the cross-chain bridge of BNB Chain, and minted 2 million BNB worth roughly $570 million out of thin air. The bridge verified inbound messages from the BNB Beacon Chain using Cosmos IAVL Merkle range proofs, and the verifier had two compounding defects: it computed the tree root from the left path only (ignoring any right child), and it never rejected proof path nodes that carried both a left and a right child. So the attacker took a real, years-old proof (a 0.05 BNB transfer whose root was already trusted), kept its left path intact so the root hash stayed identical, then injected a crafted leaf authorizing a mint into a node's right field with an empty inner node for padding. After depositing 100 BNB to register as a relayer, the forged package passed the iavlMerkleProofValidate precompile at address 0x65 and the handlePackage() handler minted 1 million BNB to the attacker, executed twice. No existing user funds were touched: every stolen token was freshly minted. BNB Chain then halted its validators, freezing the bulk of the loot on-chain, so only about $100 to $137 million ever escaped to other networks.