# Attacker Drains $7.45 Million From an Avalanche Safe Using an Approval Granted Months Earlier to an Empty Address

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.

- Published: 2026-10-29T05:42:25.188Z
- Canonical: https://polylog.news/crypto/2026-10-29/attacker-drains-7-45-million-from-an-avalanche-safe-using-an
- Publisher: Polylog (Crypto desk)
- Section: crypto
- Sources: [DeFiHackLabs](https://github.com/SunWeb3Sec/DeFiHackLabs/commit/0a9b9fd81c50767ff49f81089fbf8934f2f45b02), [DeFiHackLabs](https://github.com/SunWeb3Sec/DeFiHackLabs/commit/331942571123b92cc5670eb2e23454344d384f0f), [DeFiHackLabs](https://github.com/SunWeb3Sec/DeFiHackLabs/commit/b89dfbe9ff1093b05a08cbafb6b138eb44e43b4d), [Ethereum Research](https://ethresear.ch/t/secure-transaction-verification-and-authorization-stva/26192), [Bitcoin Magazine](https://bitcoinmagazine.com/technical/centralized-exchange-and-defi-losses-dominate-2026-crypto-hacks-despite-hardware-wallet-failures)

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](https://github.com/SunWeb3Sec/DeFiHackLabs/commit/0a9b9fd81c50767ff49f81089fbf8934f2f45b02) on Thursday under the name "approval-squat," and the [pull request](https://github.com/SunWeb3Sec/DeFiHackLabs/pull/1313) 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](https://dev.to/pandasecurity/avalanche-safe-a-stale-approval-to-an-empty-address-3kda). 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](https://www.cryptotimes.io/2026/10/27/avalanche-safe-loses-7-45m-to-misconfigured-approvals-mev-bot-front-runs-exploit/) 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](https://github.com/SunWeb3Sec/DeFiHackLabs/commit/331942571123b92cc5670eb2e23454344d384f0f). A separate commit reproduced a [March 2026 exploit of dTRINITY's dLEND market](https://github.com/SunWeb3Sec/DeFiHackLabs/commit/b89dfbe9ff1093b05a08cbafb6b138eb44e43b4d). 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](https://www.cryptotimes.io/2026/10/02/flashloopadapter-exploit-drains-305k-from-two-aave-linked-safes/) from two Safes linked to Aave through a module the Safes had authorized. Data from Lightning.news cited by [Bitcoin Magazine](https://bitcoinmagazine.com/technical/centralized-exchange-and-defi-losses-dominate-2026-crypto-hacks-despite-hardware-wallet-failures) 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](https://ethresear.ch/t/secure-transaction-verification-and-authorization-stva/26192). 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.

## 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

- Whether Safe or major wallet vendors ship warnings for approvals granted to addresses with no deployed code on the current chain. That would move the fix from individual operators to the default interface.
- Whether the bounty leads to a return of funds from the front-running bot, which would show whether MEV operators treat captured exploit proceeds as returnable.
- New DeFiHackLabs entries tagged with stale or cross-chain approvals, which would confirm that attackers are scanning for this pattern at scale.
