Morning Edition · Thursday, October 29, 2026Published at 1:42 AM EDT · New York
No signer key was stolen or phished. The multisig had given unlimited spending rights to an address that anyone could later deploy a contract to, and the owners have offered a 42,500 WAVAX bounty after an automated bot front-ran the attacker.

On October 26 an attacker emptied a 2-of-7 Safe multisignature wallet on Avalanche C-Chain that held about $7.45 million of trading inventory. The loss happened in a single block. The security research archive DeFiHackLabs added a proof-of-concept reproduction on Thursday under the name "approval-squat," and the pull request documents the attack sequence.
The root cause was a stale token approval. On March 7, 2026, the Safe granted unlimited spending approvals for USDC, WAVAX, WETH.e and BTC.b to the address 0x3725bd4d175283108156c3f15f86e1c51266155d, according to a technical write-up by Panda Security. No contract existed at that address on Avalanche. The address is the 13th deployment output of a Safe "CreateCall" helper contract. Because the helper's deployment addresses can be computed in advance, anyone could reproduce them. A token approval is tied to the address itself, not to the party that intended to use it. Whoever deployed code there first could spend the allowance.
The attacker deployed the CreateCall helper on Avalanche through the standard singleton factory. The attacker then made 12 throwaway deployments to advance the helper's counter and deployed a sweeper contract as the 13th, which landed on the approved address. The sweeper called transferFrom on all four tokens and pulled the Safe's full balances. Crypto Times reported that a bot that copies profitable pending transactions (a maximal extractable value, or MEV, bot) front-ran the original attack transaction. The Safe's owners then offered a 42,500 WAVAX bounty for the return of the funds. No outlet has reported a recovery or attributed the attack. As the Panda Security analysis puts it, the Safe contracts "did exactly what they were built to do."
The same DeFiHackLabs update brought the archive's incident count to 904. A separate commit reproduced a March 2026 exploit of dTRINITY's dLEND market. In that exploit an attacker inflated the liquidity index of an empty lending market, a rounding attack against freshly launched pools. Earlier this month, an adapter exploit drained about $305,000 from two Safes linked to Aave through a module the Safes had authorized. Data from Lightning.news cited by Bitcoin Magazine puts net 2026 crypto hack losses at roughly $2.35 billion after freezes and returns.
On the defensive side, a draft Ethereum Request for Comments (ERC) posted to Ethereum Research proposes a standard for Secure Transaction Verification and Authorization. It would create a common interface for human-readable transaction simulation, "scoped authorization" and independent checks of signing payloads for ordinary wallets, smart accounts and multisigs. The draft comes from a pseudonymous author and has no client or wallet commitments. Simulation at signing time would not have caught the Avalanche loss, because the March approval did what its signers intended. The scoping element, bounded and expiring permissions, addresses the actual failure.
Part of a tracked trend
Losses Move to Components That Worked as Designed
A growing share of DeFi losses will come not from buggy contract code but from components behaving exactly as specified — oracle forwarders, validator signature sets, governance votes and other trusted off-contract inputs — so audits and bug bounties scoped to on-chain code keep missing the failure surface, and protocols will be repeatedly forced to extend review, scope and monitoring to their privileged operational infrastructure.
Start a discussion in Townsquare.
More from this edition
What this means
The exposure sits with professional operators who run the same Safe configuration across many Ethereum Virtual Machine (EVM) chains: market makers, treasuries and protocol multisigs. Deterministic deployment means that an address controlled on one chain can be claimed by anyone on a chain where it is still empty. The documented precedent is Wintermute in 2022. Optimism sent 20 million OP tokens to a Wintermute multisig address that did not yet exist on Optimism, and an attacker replayed the factory deployment to take the address. Four years later, the same class of mistake has reached token approvals. Audits scoped to contract code do not catch it, because nothing in the code was faulty. The consensus treats this as one desk's operational error. The desk reads it as a repeatable pattern: an attacker can scan for every unlimited token approval tied to an address that remains empty on its chain, then deploy a contract there to claim it. The likelier outcome is at least one copycat drain of a stale approval within weeks, followed by approval-revocation sweeps and chain-aware deployment checks from Safe-based operators within months. That read holds only if attackers have not already harvested most such approvals. It is wrong if no comparable incident appears by the first quarter of 2027.
What to watch
Observations to monitor, not financial advice.
Synthesized from: DeFiHackLabs · DeFiHackLabs · DeFiHackLabs · Ethereum Research · Bitcoin Magazine
Comments
0No comments yet.