Key points

  • An attacker used a flawed authorized helper module to extract roughly 2,900 rsETH, valued at about $7.7 million to $7.8 million at the time.
  • An MEV searcher called Yoink copied and front-ran the public exploit transaction, capturing about 2,882 rsETH before the original attacker.
  • Security researchers said Safe's core contracts and Kelp's rsETH contracts were not compromised; the affected wallet's custom module was the weak point.

An attacker exploited a custom module connected to an Ethereum Safe wallet on September 15, extracting roughly 2,900 rsETH worth about $7.7 million to $7.8 million at the time. The original exploiter did not ultimately receive most of the assets. An automated maximal extractable value searcher known as Yoink observed the transaction in Ethereum's public queue, copied it and paid to have its version processed first. The bot captured about 2,882 rsETH, leaving the funds at a new address whose future disposition remained unresolved at the time of verification.

The weakness was an approved helper module

Blockaid's initial incident report traced the extraction to a public keeper multicall that drove a custom Uniswap v4 liquidity module already authorized by the wallet. Security researchers at AstraSec, SlowMist and BlockSec subsequently pointed to a flawed authorization check in the helper's Multicall logic. The check could approve a call when its target was set to the helper contract itself, allowing an outsider to pass instructions through a component the wallet had trusted. Because Safe modules can execute transactions without collecting the usual owner signatures each time, excessive or defective module permissions can bypass protections users expect from a multisignature wallet.

Related reporting: Tonkeeper becomes Keeper and expands wallet to seven networks

Safe and rsETH core contracts were not breached

The available incident reports distinguish the custom integration from Safe's underlying smart-account contracts. Blockaid described the event as module-authorization abuse affecting one Safe rather than an owner-key or Safe-core vulnerability. Kelp DAO, the issuer of rsETH, also said its protocol remained secure and that rsETH stayed fully backed. That distinction is important: the incident involved a wallet owner's approved external execution path, not evidence that every Safe wallet or rsETH holder was exposed to the same flaw. The identity of the affected wallet owner was not disclosed in the reviewed sources.

Yoink copied the attack from the public mempool

The attacker broadcast the exploit through Ethereum's public transaction queue. Yoink detected the profitable call and submitted a competing version with a payment of roughly 19 ETH, reported at about $46,000 to $47,000, to secure earlier placement in the block. The bot's transaction executed first, while the original attempt failed to collect the main payout. This type of transaction ordering is commonly called MEV. It prevented the initial attacker from taking most of the assets, but it did not automatically restore them to the victim or make the bot a verified white-hat actor.

Kelp imposed a temporary pause

Kelp DAO said it detected suspicious activity involving the address that received the rsETH and placed that address under a temporary 24-hour pause. During the window, rsETH could not move into or out of the address. Kelp said minting, withdrawals and other protocol functions were unaffected. A targeted pause can create time for investigation, but the announcement did not establish a permanent recovery, a return agreement or a final allocation of the intercepted funds. Those outcomes require further confirmation rather than inference from the address restriction.

The broader lesson is about delegated permissions

The incident illustrates how a secure base wallet can still be exposed by software granted authority around it. Automation modules, trading executors and liquidity-management tools can reduce friction, but their permissions and validation rules become part of the wallet's security boundary. For operators, the relevant questions include which modules can execute without new signatures, which entry points are publicly callable and whether target-address checks can be manipulated. For users, the confirmed facts remain specific: one custom Safe configuration was exploited, an MEV bot intercepted most of the rsETH, and the assets' final recovery status had not yet been established.

Sources

AI-generated editorial image; not a photograph of the reported event. Prepared with AI assistance and source verification.