πŸš€ Premium Banner Placement β€” Reach 100K+ daily crypto readersAdvertise with us β†’
LIVE
BTCβ€”ETHβ€”SOLβ€”BNBβ€”XRPβ€”ADAβ€”AVAXβ€”DOGEβ€”LINKβ€”DOTβ€”MATICβ€”ATOMβ€”LTCβ€”TRXβ€”TONβ€”BTCβ€”ETHβ€”SOLβ€”BNBβ€”XRPβ€”ADAβ€”AVAXβ€”DOGEβ€”LINKβ€”DOTβ€”MATICβ€”ATOMβ€”LTCβ€”TRXβ€”TONβ€”
β€”β–²0.0%
DeFi

A Bot Beat the Attacker to $7.8M Drained From a Safe Wallet

16 Sept 2026by CryptoJazz Admin1 min read8 views
A Bot Beat the Attacker to $7.8M Drained From a Safe Wallet

A Safe wallet on Ethereum lost about $7.8 million of restaked ether early on Tuesday. The attacker who engineered it came away with nothing. Security firms traced the opening to a module the wallet owner had authorized himself, not to Safe's own contracts. The attacker steered that module into a Uniswap v4 pool built minutes earlier around a worthless token, where a custom hook unwrapped the position into transferable rsETH. A bot called yoink saw the transaction waiting in the public mempool and front-ran it inside the same block.

The check that checked nothing

The flaw sat in the owner's code. Blockaid's reconstruction, quoted by Coinpedia, describes a custom Uniswap v4 liquidity-provider module with a public entry point that accepted caller-controlled data and used DELEGATECALL without proper access checks. That instruction lets one contract run another's code against its own storage. A missing permission check there is expensive for exactly that reason. AstraSec described it differently to CoinDesk, putting the root cause in a flawed authorization check in a Multicall contract that approved anyone who named the helper itself as the target. The two descriptions point at the same door. BlockSec, Blockaid and SlowMist all placed the defect outside Safe's core contracts.

One block, two claimants

Timing is on chain. The drain transaction sat in block 25980525 at 04:38:47 UTC, and yoink executed in that same block, according to The Crypto Times. CoinDesk reported that the bot paid roughly $47,000 in gas to get ahead of the queue, a figure no other account read for this piece carried. The bot then moved 2,882.37 rsETH to a separate address and swapped 17.63 rsETH on Uniswap v4. Whoever runs it has said nothing publicly.

Figures that do not line up

The size of the loss depends on who counted it. CoinDesk, The Crypto Times and Metaverse Post all give roughly 2,900 rsETH worth about $7.8 million. PeckShield's alert put it at $7.81 million. Coinpedia says the wallet held about $7.73 million in rsETH before the attack. They do not reconcile, and none of the accounts explains the gap. A second divergence sits in the hour after the drain, where Metaverse Post describes about $160,000 of smaller transactions while The Crypto Times logs a single later transaction at 05:53:59 UTC involving 157.71 rsETH. Neither figure confirms the other.

Kelp paused one address

Kelp DAO, which issues rsETH, moved at 06:03 UTC. It placed the receiving address under a temporary 24-hour pause, blocking the token in or out of that one address and nothing else.

"This is a precautionary, wallet-level measure only. Kelp contracts are safe, rsETH remains fully backed, and all operations...are running normally," the team said, in the wording The Crypto Times carried.

Metaverse Post rendered the same statement in different words, naming minting, withdrawal and integration operations one by one. We could not establish which wording is the original. What both versions guard is the distinction the incident turns on: the issuer's contracts were never the thing that failed, and the collateral behind rsETH was never in question.

Still no owner, still no answer

The victim has not been identified beyond an address. Nothing published so far says whether the bot operator intends to return anything, and the pause on the receiving address was temporary by design. Bots taking what attackers reach for is not new, and neither is the pattern underneath it. A bridge bug at Symbiosis that minted 46 billion syBTC ended with a negotiated return, and that is the outcome nobody has confirmed here. The year's running tally leans toward stolen keys over code bugs, and this one was neither. It was a permission the owner wrote himself.

Read also: PeckShield Counts 50 August Hacks, CertiK Puts Losses $79M Higher

← All news