TL;DR
▶ On September 15, 2026, an attacker exploited a flaw in a Gnosis Safe wallet on Ethereum and attempted to drain 2,900 rsETH worth approximately $7.8 million.
▶ The attacker made one critical mistake: they broadcast the exploit transaction into the public mempool where anyone could see it.
▶ An automated MEV bot nicknamed Yoink spotted the attack, paid $47,000 in gas fees to jump the queue, and executed the same exploit first.
▶ The hacker received exactly zero dollars. The wallet owner lost $7.8M. Yoink walked away with 2,882 rsETH routed to its own address.
▶ Root cause: a flawed authorization check in a custom Multicall helper contract the wallet owner had whitelisted. Not a Safe flaw. Not a KelpDAO flaw. A misconfigured helper.
▶ KelpDAO paused the affected address for 24 hours. Its core contracts are secure and rsETH remains fully collateralized.
On the morning of September 15, 2026, an attacker spotted a vulnerability in a Gnosis Safe wallet holding approximately 2,900 rsETH worth $7.8 million and launched an exploit to drain it. Blockchain security firms Blockaid, BlockSec, SlowMist, and PeckShield all detected the transaction immediately. So did an automated MEV bot called Yoink.
Yoink did not stop the attack. It did not alert the victim. It did not contact law enforcement. It calculated that the attack would succeed, paid approximately $47,000 in priority gas fees to have its own transaction processed before the attacker’s, executed the exact same exploit, and took every single rsETH token for itself. The attacker’s transaction then arrived, found an empty wallet, and completed with nothing to show for it.
The final scoreboard: the original wallet holder lost $7.8 million. The hacker lost their $47,000 in gas fees and got zero. Yoink received 2,882 rsETH routed to address 0xC70f00…E461686b. In the history of crypto exploits, this is a genuinely rare outcome. The attacker executed a successful technical exploit and walked away with nothing because an automated bot was faster, smarter, and completely amoral about whose money it took.
What Is the Mempool and Why Did It Cost the Hacker Everything?
What is the mempool?
When you submit a transaction on Ethereum, it does not go directly into a block. It first sits in a waiting room called the mempool (memory pool), a public queue of pending transactions that all network participants can see. Miners and validators select which transactions to include in the next block, typically prioritising those that pay higher gas fees. The mempool is completely transparent. Anyone watching it can see your transaction, what it does, and what it will produce if it succeeds. This transparency is what MEV bots exploit: they watch the mempool for profitable transactions, then pay more gas to execute the same or a better version before the original transaction lands.
The attacker in this incident submitted their exploit transaction to the public Ethereum mempool. This was their fatal error. A private mempool or a direct block-builder submission would have hidden the transaction from other actors until it was already included in a block. In the public mempool, the transaction was visible to every MEV bot on the network from the moment it was submitted.
Yoink operates as a front-running bot: it scans the mempool continuously for transactions that will produce a profitable outcome, then submits an identical or superior transaction with a higher gas tip to ensure it is processed first. The economics are simple. Yoink sees a transaction that will move 2,882 rsETH worth $7.8 million if it succeeds. It pays $47,000 in gas, a 0.6% fee, to ensure its version goes first. The expected profit is $7.75 million. That is an obvious trade.
From Yoink’s perspective, it does not matter whether the transaction it is front-running is legitimate or malicious. It does not know or care that the transaction was an exploit. It sees a profitable outcome in the mempool and executes the same logic faster. This is precisely what makes MEV bots both fascinating and ethically uncomfortable: Yoink is not a white hat. It did not rescue $7.8 million for the victim. It took $7.8 million for itself. The only party that benefited from Yoink’s action is Yoink.
What Was the Actual Vulnerability? The Flawed Authorization Check Explained
What is a Gnosis Safe?
Gnosis Safe (now just ‘Safe’) is the most widely used smart contract wallet on Ethereum. Unlike externally owned accounts (regular wallets controlled by a private key), Safe is a smart contract that can be programmed with custom logic: multiple required signers, time delays, spending limits, and whitelisted modules that can execute transactions on the wallet’s behalf. This programmability is powerful for institutions and sophisticated DeFi users who need automated treasury management. It is also a surface area for bugs: every custom module, hook, or helper contract you add to a Safe is code you are trusting with your funds.
The victim’s Gnosis Safe wallet was configured to use a custom helper contract called a Strategy Executor or Multicall module. This is a common setup for DeFi power users who automate trading strategies: instead of manually signing every transaction, they whitelist a helper contract that can execute predefined operations on the wallet’s behalf automatically.
The flaw, confirmed by BlockSec, SlowMist, and AstraSec, was in the authorization check inside the Multicall contract. The helper was supposed to verify that the caller had permission to trigger actions on the wallet. But the check was implemented incorrectly: it approved any caller who named the helper contract itself as the target address. In other words, if you told the helper “I want to call you,” it said yes, regardless of who you were. The check verified the destination, not the caller. Anyone in the world could trigger the helper, and the helper would execute with the full permissions it had been granted by the wallet.
The attacker used this to route the wallet’s aEthrsETH tokens (an Aave-wrapped version of Kelp DAO’s restaked ETH) through a malicious Uniswap v4 liquidity pool the attacker had deployed minutes earlier. A custom hook in that pool unwrapped the aEthrsETH into raw rsETH and siphoned it out. The wallet was left holding a worthless liquidity position receipt. The entire sequence worked because one authorization check approved the wrong thing.
What Actually Happened: The Exploit and Front-Run Step by Step
Victim sets up a custom Multicall helper module on their Gnosis Safe
The module is whitelisted to execute transactions on behalf of the wallet. Designed for automated DeFi strategy execution. Contains a flawed authorization check that approves any caller who names the module as the target.
Attacker deploys a malicious Uniswap v4 pool minutes before the attack
The pool is created around a worthless token called ‘Permissionless Attacker Token’ (PAT). A custom hook is embedded that will unwrap aEthrsETH into raw rsETH when triggered.
Attacker calls the victim’s Multicall module exploiting the auth flaw
Because the authorization check approves anyone who names the module itself as target, the attacker gets full execution rights. They redirect the wallet’s aEthrsETH into the malicious pool.
Attacker broadcasts this transaction to the PUBLIC mempool
This is the fatal mistake. The transaction is now visible to every MEV bot on the network before it is included in a block.
Yoink detects the pending exploit in the mempool
Yoink calculates: this transaction will move 2,882 rsETH worth $7.8M if it succeeds. Cost to front-run: ~$47,000 in gas fees. Expected profit: ~$7.75M. Decision: go.
Yoink submits the identical transaction with a higher gas tip
By paying more gas Yoink’s transaction is processed by validators before the attacker’s. Yoink captures all 2,882 rsETH and routes it to its own address 0xC70f00…
Attacker’s transaction executes into an already-drained wallet
The wallet has no rsETH left. The attacker receives nothing. Their gas fees are gone. The exploit succeeded technically and produced zero.
KelpDAO detects suspicious activity and pauses the affected address
24-hour temporary pause on the compromised address. Core rsETH contracts confirmed secure. rsETH remains fully collateralized.
Sources: CoinDesk September 15 2026, BlockSec, Blockaid, SlowMist, AstraSec, Coinpedia | @cryptonewsbytes
How the Yoink Front-Run Worked: Two Races, One Winner
Source: BlockSec, Blockaid, SlowMist, CoinDesk September 15 2026 | @cryptonewsbytes
😈 The Hacker
Spots the flawed Multicall module
Authorization check approves any caller who names the module as target
Deploys malicious Uniswap v4 pool
Custom hook will unwrap aEthrsETH into raw rsETH and drain it out
🚧 Broadcasts exploit to PUBLIC mempool
FATAL MISTAKE. Everyone can see this transaction.
⏳ Waits to be included in a block
Normal gas fee. Gets in line. But someone else is already moving.
Transaction executes… on an empty wallet
Every rsETH is already gone. Wallet holds a worthless LP receipt.
Hacker receives: $0
Gas fees paid and lost
VS
🤖 Yoink MEV Bot
Scans the mempool continuously
Watching every pending transaction for profit opportunities
Detects the hacker’s transaction
Simulates it: this will move 2,882 rsETH worth $7.8M if it succeeds
⚡ Pays $47,000 in gas to jump the queue
Submits identical exploit with higher gas tip. Gets processed FIRST.
Executes the exploit first
Routes 2,882 rsETH through the malicious pool. Hook unwraps tokens.
Routes rsETH to its own address
2,882 rsETH sent to 0xC70f00…E461686b. All done before hacker lands.
Yoink receives: $7.8M rsETH
Net profit after $47K gas: ~$7.75M
Final Outcome
Original wallet owner
Lost $7.8M
Hacker
Got $0
Yoink bot
Kept $7.8M
Source: CoinDesk Sep 15 2026, BlockSec, Blockaid, SlowMist, AstraSec | @cryptonewsbytes
What Is MEV and Is Yoink Doing Something Illegal?
What is MEV (Maximal Extractable Value)?
MEV stands for Maximal Extractable Value, the profit that can be extracted from a blockchain by controlling which transactions are included in a block and in what order. MEV bots exploit the transparency of the public mempool to identify profitable opportunities: arbitrage between DEX prices, liquidation of undercollateralized loans, and front-running of large trades. The term was originally ‘Miner Extractable Value’ when proof-of-work miners controlled ordering. After Ethereum’s transition to proof-of-stake, ‘Maximal’ replaced ‘Miner’ since validators now control block ordering.
Whether what Yoink did is illegal is a genuinely interesting legal question with no settled answer. Yoink took funds that had just been exploited from a victim’s wallet. It did not attack the victim directly. It intercepted stolen goods that a third party was in the process of stealing. In most legal systems, intercepting stolen property does not automatically give you title to it. The property still belongs to the original victim.
In practice, the enforceability of any legal claim against an anonymous MEV bot operating on a public blockchain is close to zero. Yoink’s operator is unknown. The funds are sitting at an Ethereum address with no KYC, no identity, and no jurisdiction. The victim’s most realistic path to recovery is not a lawsuit but a direct on-chain negotiation: reach out to the Yoink operator through a signed on-chain message offering a bounty for the return of funds, which has worked in some high-profile MEV cases before.
It is worth noting that Yoink has done this before. The Ronin bridge exploit in August 2024 was famously front-run by Frontrunner Yoink, which captured over $10 million. In that case, Yoink’s operator returned most of the funds and kept $500,000 as a bug bounty. Whether the same operator is involved here and whether they will return funds is unknown at the time of writing.
What KelpDAO, Safe, and rsETH Holders Need to Know
Three distinct systems have been implicated in this incident by name, and the blame picture is important to understand correctly. Safe’s core contracts are not at fault. The vulnerability was in a custom Multicall module the victim had chosen to add to their Safe, not in Safe’s own code. AstraSec, BlockSec, and SlowMist all confirmed this explicitly. Safe wallets without the flawed custom module are not affected.
KelpDAO’s rsETH contracts are not at fault. KelpDAO issued rsETH, which is what was drained. But the drain happened because of the wallet’s misconfigured helper contract, not because of any flaw in how rsETH is issued or redeemable. KelpDAO confirmed on X that rsETH is fully collateralized and its core contracts are secure. The 24-hour pause on the specific affected address was a precautionary measure, not an indication of a systemic problem.
The flaw was entirely in the victim’s custom Multicall helper contract. Specifically in the authorization check that verified the wrong thing: destination address instead of caller identity. This is a DeFi configuration mistake, not a protocol exploit. The lesson for every DeFi power user who runs automated strategies through whitelisted helper contracts: the authorization logic in every custom module you add to a Safe is code you are trusting with the entirety of the funds in that wallet. A single flawed check is sufficient to lose everything.
The Irony: A Hacker Out-Hacked by a Bot
The outcome of this incident is genuinely unusual in the history of crypto exploits. In the vast majority of on-chain hacks, the attacker succeeds and the victim loses funds with limited recourse. In the rare cases where funds are recovered, it is typically through white-hat intervention, protocol pauses, or negotiated return. In almost no case does the attacker themselves lose the stolen funds to a third party before they can even pocket them.
What happened here is different. The attacker executed a technically successful exploit of a real vulnerability in a real wallet holding real money. The authorization check was broken. The malicious Uniswap v4 pool worked as designed. The aEthrsETH was correctly unwrapped and the rsETH moved out of the wallet. Everything the attacker built functioned perfectly. They just published their masterplan to the public mempool before they had actually gotten paid.
In the Ethereum mempool, that is equivalent to robbing a bank and then standing outside announcing which exit you’re leaving from. Yoink was at the exit. The hacker went home with nothing. The Hacken Q2 2026 Security Report CNB covered noted that 88% of crypto losses in Q2 2026 came from operational and key management failures rather than smart contract exploits. This incident adds a new category: losing your stolen funds to a faster bot because you failed to use a private mempool.
Frequently Asked Questions
What is the Yoink MEV bot?
Yoink is an automated MEV (Maximal Extractable Value) bot that monitors the Ethereum public mempool for profitable transaction opportunities and front-runs them by paying higher gas fees to ensure its transaction is processed first. It is not a white-hat security tool and does not return funds to victims. It is a profit-seeking automated program that in this case captured $7.8M in rsETH by front-running a hacker’s exploit transaction.
Did the original wallet owner get their money back?
No. As of September 15, 2026, the 2,882 rsETH is sitting at address 0xC70f00CD7E461686b04B0E912E309becA8b80ea0 controlled by the Yoink bot operator. The wallet owner has not publicly confirmed any recovery. The most realistic path to recovery is an on-chain negotiation offering the Yoink operator a bounty, which has worked in similar MEV front-run cases including the 2024 Ronin bridge incident where Frontrunner Yoink returned most of the funds and kept $500,000.
What is the mempool and why did it matter here?
The mempool is a public queue of pending Ethereum transactions that all network participants can see before they are included in a block. By broadcasting the exploit transaction to the public mempool, the attacker made it visible to every MEV bot on the network. Yoink saw the transaction, recognised it would succeed and produce 2,882 rsETH, paid $47,000 in gas fees to process its copy first, and captured the entire amount. Using a private mempool or direct block-builder submission would have hidden the transaction.
Is Safe or KelpDAO’s rsETH affected?
No. Safe’s core contracts are not at fault. The vulnerability was in a custom Multicall helper module the wallet owner had added to their Safe, not in Safe’s own code. KelpDAO confirmed its rsETH contracts are secure and rsETH is fully collateralized. The 24-hour pause applied only to the specific compromised address. All other Safe wallets and rsETH holders are unaffected.
What was the actual vulnerability?
The custom Multicall strategy-executor module whitelisted by the victim’s Gnosis Safe contained a flawed authorization check. Instead of verifying the identity of the caller, it verified the target address of the call, approving anyone who named the module itself as the target. This meant any external caller could trigger the module with full wallet permissions. The attacker used this to route the wallet’s aEthrsETH through a malicious Uniswap v4 pool that unwrapped and drained the tokens.
Is what Yoink did legal?
This is legally unsettled. Yoink intercepted funds being stolen from a victim, but the interception gave those funds to Yoink rather than returning them to the victim. In most legal systems, intercepting stolen property does not give the interceptor title to it. However, enforcing any legal claim against an anonymous MEV bot on a public blockchain is practically near-impossible. The victim’s most realistic option is an on-chain negotiation offering the Yoink operator a bounty for voluntary return of funds.
Further Reading
The Hacken Q2 2026 Security Report on the operational failures behind the majority of crypto losses. This incident adds a new variant: a technically successful exploit that failed to deliver any profit because of a public mempool mistake.
The July 2026 Wanchain bridge exploit: another case where a trusted third-party component failed. The Yoink incident and the Midnight bridge hack both show that trusted helper infrastructure is a primary attack surface in 2026.
Another trusted infrastructure failure from July 2026: a private key leaked through a GitHub configuration mistake, not an on-chain exploit. Trusted helper infrastructure is the primary attack surface whether the key is on GitHub or in a whitelisted contract.
Sources: CoinDesk September 15 2026 (primary: coindesk.com/business/2026/09/15), Blockaid X post September 15 2026 (primary detection), BlockSec (Phalcon) X post September 15 2026 (primary technical analysis), SlowMist X post September 15 2026 (primary confirmation), AstraSec X post September 15 2026 (root cause: flawed authorization check in Multicall contract), KelpDAO X post September 15 2026 (rsETH fully collateralized, core contracts secure), Coinpedia September 15 2026 (attack mechanics detail), mpost.io September 15 2026 (MEV front-run confirmation) | Published September 15, 2026 | CryptoNewsBytes.com | Not financial advice.
