# The Hacker Who Lost $7.73M to a Bot — rsETH Safe Module Exploit

On September 15, 2026, someone found a bug in a custom router module attached to a Gnosis Safe holding over $7.73 million in Aave-wrapped rsETH. They built the exploit, submitted it to the mempool — and an MEV bot named Yoink copied the transaction and executed it first. The attacker showed up an hour later to scrape leftovers.

This write-up covers what I was able to verify on-chain and what I had to rely on others for. The router's source code is not published on Etherscan, so the internal vulnerability mechanism comes from SlowMist's bytecode analysis, credited below. Everything else — the Safe configuration, the money flow, the attacker timeline, and the current state — I read directly from the chain.

* * *

## The Safe

Address: [`0x40E93a52F6Af9fCD3b476aeDADD7FeABD9f7AbA8`](https://etherscan.io/address/0x40E93a52F6Af9fCD3b476aeDADD7FeABD9f7AbA8)

A Gnosis Safe (v1.3.0) with three owners and a threshold of one:

| Owner | Address |
| --- | --- |
| Owner 1 | `0x8c2aeccef3b3634d039c96993577f80d3278fee8` |
| Owner 2 | `0x5f411b4485741e5a437fcc1ef103fbeb461158ca` |
| Owner 3 | `0xe32e3bd2ec560513cab4757564ca50d13caf9f7f` |

**Threshold: 1-of-3.** Any single owner could authorize transactions. Verified via `getOwners()` and `getThreshold()` on-chain.

The Safe had a custom module enabled: a router contract at [`0x4f0055926c839D1d960a82CBF84E2eE933958ebC`](https://etherscan.io/address/0x4f0055926c839D1d960a82CBF84E2eE933958ebC) (2,127 bytes, source not verified on Etherscan). This module had the ability to execute transactions on the Safe without requiring owner signatures — that is the intended behavior of Safe modules. The bug was in the router's own authorization logic.

Post-exploit, the module has been removed. `isModuleEnabled(0x4f0055...)` currently returns `false`.

* * *

## The vulnerability

**Source:** [**SlowMist**](https://x.com/SlowMist_Team/status/2099779127662493875)**, who identified this from bytecode analysis. I have not independently verified the router's internal logic because the source code is not published.**

The router exposed a `multicall(address, bytes[])` function. When called with the first argument set to `address(this)` (the router's own address), the inner `_isAuthorized` check passed because `msg.sender` in the inner call context was the router itself — which was an authorized module on the Safe. This allowed anyone to construct a multicall that the router would execute as if it were an authorized caller.

[AstraSec](https://x.com/AstraSecAI/status/2099775550802059527) and [Blockaid](https://x.com/blockaid_/status/2099732957803999342) published consistent analyses within hours.

* * *

## What happened — the Yoink

Block: [25980525](https://etherscan.io/block/25980525) Time: September 15, 2026, 04:38:47 UTC

The exploit transaction:

[`0x0e7680b06cb8a6f86c149d9ba90d98e3d334e7b072dde03909d43fcfd98a8705`](https://etherscan.io/tx/0x0e7680b06cb8a6f86c149d9ba90d98e3d334e7b072dde03909d43fcfd98a8705)

| Field | Value |
| --- | --- |
| from | `0xfde0d1575ed8e06fbf36256bcdfa1f359281455a` |
| to | `0x80bf7db69556d9521c03461978b8fc731dbbd4e4` |
| gas used | 3,207,685 |
| logs | 39 events |

The `from` address is **not the attacker**. It is an MEV bot operator. The attacker (`0x2f7e143e27f2fa26ef3b8ac72698f1d321422f67`) submitted the exploit transaction to the public mempool. Yoink — an MEV bot — saw it, extracted the calldata, and submitted an identical transaction with a higher gas price. The bot's transaction landed in block 25980525. The attacker's original transaction was displaced.

* * *

## Money flow

Reconstructed from ERC-20 Transfer event logs on the exploit TX receipt:

```plaintext
Step 1: Safe (0x40e93a) sends 2,900 aEthrsETH to Uni V4 / Permit2
        Token: aEthrsETH (0x2d62109243b87c4ba3ee7ba1d91b0dd0a074d7b1)

Step 2: Helper (0x10605ee48ff9...) unwraps aEthrsETH
        → burns 2,900 aEthrsETH (to 0x0000...0000)
        → receives 2,900 rsETH from Aave
        
Step 3: rsETH flows through Uni V4 to MEV bot (0x80bf7db6...)

Step 4: MEV bot distributes:
        → 2,882.3674 rsETH to Yoink wallet (0xC70f00CD7E461686b04B0E912E309becA8b80ea0)
        → 17.6326 rsETH to Uni V4 (swap fee / hook)
```

Total extracted from Safe: **2,900 aEthrsETH ≈ $7.73M** at the time.

* * *

## The attacker's timeline

The attacker (`0x2f7e143e27f2fa26ef3b8ac72698f1d321422f67`) has 11 total transactions, all after the Yoink. Verified from Etherscan:

| Time (UTC) | Action | Notes |
| --- | --- | --- |
| 05:43:35 | Contract creation | Exploit contract deployment |
| 05:43:35 | Call to 0x94Fcd3... | Setup |
| 05:44:47 | rsETH token call | Approval (Transfer event = Approval log) |
| 05:49:23 | Contract creation | Second contract |
| 05:49:23 | Call to 0x9c904c... | Setup |
| 05:49:59 | Contract creation | Third contract |
| 05:49:59 | Call to 0x9c904c... | Setup |
| 05:50:23 | Call to 0x4C82D1... | Unknown |
| 05:51:35 | Tornado Cash Router | **10 ETH sent to Tornado Cash** |
| 05:58:23 | Contract creation | Fourth contract |
| 05:58:23 | Call to 0xe196E5... | Unknown |

The attacker deployed four contracts and sent 10 ETH to Tornado Cash. Between blocks 25980878 and 25980908, the attacker managed to scrape approximately 174 aEthrsETH in small increments (0.5 rsETH per transaction) from the Safe — the leftovers Yoink didn't take.

* * *

## Current state

Verified via `eth_call` on September 15, 2026:

| Address | Role | Balance |
| --- | --- | --- |
| Safe (0x40e93a) | Victim | 0 ETH |
| Attacker (0x2f7e14) | Exploit author | 0.318 ETH |
| Yoink wallet (0xc70f00) | MEV recipient | 39.12 ETH |
| Router (0x4f0055) | Vulnerable module | Code exists, module removed from Safe |

Safe modules: **0 enabled** (router removed post-exploit). Safe threshold: still 1-of-3.

[Kelp DAO](https://x.com/KelpDAO/status/2099740756865159562) froze the Yoink recipient address (0xc70f00) within hours. Kelp's core protocol and rsETH backing are not affected — this was a user-controlled Safe, not protocol infrastructure.

* * *

## What I verified vs what I cited

| Claim | Source | My verification |
| --- | --- | --- |
| Block, time, TX hash | On-chain | ✅ Direct RPC read |
| TX from = MEV bot, not attacker | On-chain | ✅ `eth_getTransactionByHash` |
| Safe owners + threshold | On-chain | ✅ `getOwners()` + `getThreshold()` |
| Router was a Safe module | On-chain | ✅ `isModuleEnabled()` = false (removed) |
| Money flow (2,900 → 2,882 + 17) | On-chain | ✅ Transfer event logs on receipt |
| Attacker timeline (11 TXs) | On-chain | ✅ Etherscan TX list |
| Tornado Cash 10 ETH | On-chain | ✅ TX to Tornado.Cash Router |
| Attacker scraped ~174 rsETH | On-chain | ✅ `alchemy_getAssetTransfers` |
| multicall + \_isAuthorized bypass | SlowMist | ⚠️ Cited, not independently verified (router source unpublished) |
| Safe module 0xea18b... | AstraSec | ⚠️ Cited (module removed, can't verify pre-exploit state) |
| Uni V4 hook pool creation | Blockaid | ⚠️ Cited (hook address unverified) |

* * *

## The real question

The multicall bypass is the vulnerability. The MEV front-run is the plot twist. But the setup that made this possible was simpler than either:

A Safe holding $7.73M with a 1-of-3 threshold and a custom module that could move funds without owner signatures. One signature to do anything. One bug in the module to bypass even that.

The attacker found the bug. The bot found the attacker. Kelp froze the bot's wallet. The money sits at 0xC70f00, paused, waiting for whatever comes next.

* * *

*Analysis based on publicly available on-chain data. Router internal logic cited from* [*@SlowMist\_Team*](https://x.com/SlowMist_Team/status/2099779127662493875)*. No transactions submitted.*

Sources:

*   [Blockaid](https://x.com/blockaid_/status/2099732957803999342)
    
*   [SlowMist](https://x.com/SlowMist_Team/status/2099779127662493875)
    
*   [AstraSec](https://x.com/AstraSecAI/status/2099775550802059527)
    
*   [Kelp DAO](https://x.com/KelpDAO/status/2099740756865159562)