Skip to main content
Avalanche Safe: A Stale Approval to an Empty Address
Security
Security
5 min read24 views

Avalanche Safe: A Stale Approval to an Empty Address

Floriano Righetti
Floriano Righetti

On 26 October 2026, an attacker tried to drain a 2-of-7 Safe multisig on Avalanche. According to the monitoring service Defimon, it held about $7.45 million in trading inventory. The attacker did not steal a key, trick a signer or exploit a bug in the Safe contracts. The attack relied on token approvals the multisig itself had signed in March. An automated MEV bot copied the attack and executed it first. On 27 October it returned almost everything in exchange for a bounty. The mistake behind it is easy to repeat.

What happened#

On 7 March 2026 at 16:10 UTC, the Safe executed a batch transaction. In it, the Safe granted unlimited spending rights over four tokens (WAVAX, USDC, WETH.e and BTC.b) to the address 0x3725…155d. Defimon reports that the team's pool contract sits at this same address on Ethereum, Base and Arbitrum. On Avalanche, however, the address was empty. It is simply the address that Safe's public CreateCall contract produces on its 13th deployment, and CreateCall had never been used on that chain. The approvals were never revoked.

That left a standing permission that anyone could claim. Defimon describes the method: a fresh account deployed CreateCall through the Safe singleton factory and ran 12 throwaway deployments. It then placed a sweeper contract at the approved address, designed to pull every approved balance out of the Safe. No new signature from the Safe's owners was needed, because the permission already existed on-chain.

The attack transaction was sent at 12:56:14 UTC on 26 October, in Avalanche block 98,605,391. It failed. An MEV bot had copied the transaction and placed its own version first in the same block.

What we verified on-chain#

We read the relevant transactions and the Safe's current settings through Avalanche's public C-Chain RPC:

  • The March batch emitted four approvals with the maximum possible value, from the Safe to 0x3725…155d.
  • The Safe contract currently reports seven owners and a threshold of two signatures.
  • The original attack transaction reverted. The bot's transaction in the same block moved 3,090,123.58 USDC, 350,375.86 WAVAX, 181.98 WETH.e and 10.786 BTC.b out of the Safe.
  • The bot forwarded these funds to a holding address (0x11eb…9bc5) and posted on-chain messages asking for a 5-10% bounty. At 09:30:43 UTC on 27 October, one of the Safe's seven owner addresses replied on-chain: "we are happy for you to keep 42,500 WAVAX as a bounty for your help if can proceed with remaining transfers".
  • Between 09:37 and 09:47 UTC, the holding address returned all of the USDC, WETH.e and BTC.b, plus 307,834.86 WAVAX, to the address the bot had named. 42,500 WAVAX remained as the bounty. About 41 further WAVAX stayed with the bot's original address. The holding address still holds exactly 42,500 WAVAX. BlockintAI's independent reconstruction matches these figures.

The dollar values ($7.45 million at stake, about $371,000 for the bounty) are Defimon's estimates. We have not independently priced them.

Known and unknown#

Known: the root cause was a configuration error, namely an unlimited approval to an address with no code on that chain. It was not a flaw in the Safe contracts or in Avalanche. Defimon also reports that the operator's signers moved assets from Safes on several other chains into one new address from 13:48 UTC on 26 October.

Unknown: the operator has not identified itself or published a statement. The identity of the attacker and of the bot's controller is also unknown. Whether similar approvals exist on other chains has not been publicly confirmed. BlockintAI also reports fake "USDC" and "BTC.b" tokens, issued by contracts that are not the real tokens, showing transfers to a look-alike of the return address. This is a pattern associated with address poisoning.

Our view#

The funds came back because a bot chose to return them, not because a control stopped the attack. For anyone managing assets across several chains, the lesson is practical. An address is only meaningful on the chain where its code actually exists. An approval should be granted only after checking, on that specific chain, that the spender holds the expected code. Unused approvals should be revoked as routinely as old keys are rotated.

Sources#

Share this article

Related Articles

When the Server Lies: Electrum's Fee-Bump Attack

SecurityOct 26, 20264 min

When the Server Lies: Electrum's Fee-Bump Attack

A malicious Electrum server could swap a pending payment and wait for a fee bump. What the advisory confirms, what is unknown and what users should do.

Read article