Safe Multisig Exploit: MEV Bot Front-Runs $7.45M on Avalanche

On October 26, 2026, approximately $7.45 million in crypto assets was drained from a Safe multisig wallet on Avalanche C-Chain.

The underlying issue was an ERC-20 allowance misconfiguration. The Safe’s owners had granted unlimited spending allowances for four tokens to an address that hosted a trusted team contract on other blockchains but contained no deployed code on Avalanche.

An attacker identified this gap and prepared to deploy a malicious contract at the approved address. That contract could then use the existing allowances to drain the Safe.

But the attack did not unfold as its author intended.
An MEV bot detected the attacker’s pending transaction, replicated its logic, and executed first. The assets left the Safe, but they went to the bot operator rather than the original attacker.

Assets drained

According to Defimon’s investigation, the following assets were withdrawn:

• 3.09 million USDC
• 350,400 WAVAX
• 182 WETH.e
• 10.79 BTC.b

Their combined estimated value at the time of the incident was approximately $7.45 million.

Initial outcomes

The original attacker prepared the exploit and submitted the transaction, but was front-run by the MEV bot. The original transaction reverted, and its sender did not receive the drained assets.

The MEV bot successfully replicated the exploit and captured the funds. Its operator subsequently offered to return the assets to the Safe’s owners in exchange for a bounty of 5–10% of the amount returned.

The Safe’s owners lost control of approximately $7.45 million in assets. Following the incident, associated wallets on other blockchains began moving funds to a new address, apparently to protect the remaining assets.

The incident illustrates both the danger of unsafe ERC-20 approvals and the ability of automated MEV participants to copy and front-run an exploit prepared by someone else.

An MEV bot is an automated program that monitors blockchain activity and looks for opportunities to profit from transaction ordering.

A transaction submitted through the public network typically enters a pool of pending transactions, known as the mempool, before it is included in a block. While pending, it may be visible to other network participants, including MEV bots.

If a bot identifies a profitable opportunity, it can submit its own transaction and attempt to have it executed first. This is known as front-running.

For example, a bot might detect a large token purchase likely to move the price, buy ahead of it, and sell afterward at a higher price.

Trading is not the only source of such opportunities. Bots can also detect and reproduce transactions that exploit vulnerable configurations or contracts.

That is what happened here. The attacker prepared a transaction to drain approximately $7.45 million from a Safe multisig. The bot identified the opportunity, replicated the exploit, and secured execution ahead of the original transaction.

The bot operator received the funds instead of the attacker.

An MEV bot should not automatically be considered a defender. In this case, it prevented the original attacker from capturing the assets, but it also removed those assets from the victim’s wallet.

The operator later offered to return the funds in exchange for a 5–10% bounty.

Предпосылки: ошибка, допущенная за семь месяцев до атаки

The approval mistake made seven months earlier

The conditions for the exploit were created long before the funds were drained.

On March 7, 2026, the Safe’s owners executed a batch transaction granting an external address spending allowances for four tokens.

These approvals meant that a contract at the designated address could call transferFrom() to move the approved tokens out of the Safe without requiring further signatures from its owners.
ERC-20 allowances are a standard part of how DeFi applications work. Granting an allowance is not, by itself, an exploit.

The problem was the address receiving those permissions.

Preparing the exploit: targeting a predictable address
The attacker identified an address with unlimited token allowances but no deployed code. They then determined that Safe’s public CreateCall deployment mechanism could be used to deploy a contract at that address.
On Ethereum-compatible networks, a contract created with CREATE has an address deterministically derived from the creator’s address and nonce. Knowing the creator and its deployment sequence makes it possible to calculate future contract addresses.
The planned exploit followed this sequence:

1. Prepare a new externally owned account, or EOA, for the attack.
2. Use Safe infrastructure to access the public CreateCall mechanism.
3. Execute twelve intermediate contract deployments.
4. Deploy the malicious contract at 0x3725bd4d...6155d on the thirteenth creation.
5. Call the token contracts to drain the assets covered by the Safe’s existing allowances.

The malicious contract acted as a sweeper, moving available assets to addresses controlled by the party executing the exploit.

Because the ERC-20 allowances were already in place, the contract could act as the approved spender and invoke transferFrom() to move tokens from the Safe.

No compromise of the multisig signers’ private keys was required. The exploit abused previously granted permissions rather than breaking Safe’s signature verification.

Execution: the MEV bot intervenes

After preparing the exploit, the attacker submitted a transaction intended to deploy the malicious contract and drain the assets.

Original transaction:
0xf1f87d370290afe269ae8eb30fe8e5e4694ad153914a2de6d980641f4a331289

Before execution, the transaction became visible to an MEV participant capable of analyzing pending activity.
The bot identified the profit opportunity and reproduced the attack logic. Rather than letting the original attacker deploy at the predictable address and capture the funds first, it submitted its own transaction and secured earlier execution.

MEV bot transaction:
0xf88a7960a07832e1bf5be64edbd12a9e615b4f63959a4b87a147f0c63c007ed5

The bot completed the necessary operations first and captured the assets.
By the time the original attacker’s transaction was executed, the conditions required for it to succeed no longer existed. It reverted.

The attacker had effectively prepared a way to drain millions of dollars, only to lose the execution race to an automated competitor.

Negotiations to return the funds

After capturing the assets, the bot operator claimed to be acting as a white hat and expressed an intention to return the funds.

In an on-chain message, the operator stated a willingness to return the assets to:
0x35c6aa248e9495e0572598fbfe0528acbac2807c

The operator asked the owners to consider a bounty of 5–10% for identifying and intercepting the attack.
Based on the estimated $7.45 million value of the assets, this would amount to:

• 5%: approximately $372,500
• 10%: approximately $745,000

The remaining 90–95% could then be returned to the original owners.

In subsequent discussions, the bot operator agreed to retain 42,500 WAVAX, valued at approximately $371,000, and return the remaining assets to the owner.

This describes the agreed terms, rather than confirmation that the return transfers had been completed.