Yesterday's $7.8 million rsETH theft is worth a closer look, because the mechanism is more instructive than the headline number. Nothing in Safe's core contracts failed. Nothing in Kelp DAO's contracts failed. A single whitelisted helper contract with a broken permission check let an arbitrary caller execute arbitrary code inside the wallet's own context — bypassing the owner set and the signing threshold entirely.

Modules are threshold bypasses by design

A Safe module is an extension that, once enabled, can act on the wallet without assembling owner signatures. That is the feature: automated strategies, keepers and integrations need to move funds without a multisig round-trip. It is also the exposure: every enabled module is a standing authorization to spend, and the security of the wallet becomes the union of the security of all its modules — not the strength of its threshold.

In this incident, the helper's check approved any caller that named the helper itself as the target address, according to SlowMist and BlockSec. A caller-controlled DELEGATECALL into the wallet's execution context then unwound an Aave position through Permit2 and a Uniswap v4 pool whose hook answered to the attacker. The multiset of owners may as well not have existed.

This is the same class of lesson as the February 2025 Bybit theft, which began with the compromise of a third-party interface used to operate a Safe rather than the Safe contracts themselves. The industry has spent years hardening core contracts — correctly — and attackers have responded by moving to the periphery: frontends, helpers, keepers, modules, and the integration seams between them. The periphery is where the reviews are thinnest.

What hardening actually looks like

The defensive playbook for anyone running a Safe or similar smart wallet follows directly from the failure mode:

  • Review modules like core. A module with spending power deserves the same rigor as the wallet itself — a human-reviewed audit engagement scoped to the module, not a scan report and a shrug. Strategy contracts from small teams are exactly the code attackers read first.
  • Scope module permissions narrowly. A module that can DELEGATECALL arbitrary calldata in the wallet's context is not a strategy executor; it is an owner. Limit asset types, destinations, and call targets; reject DELEGATECALL unless there is no alternative.
  • Prune ruthlessly. Enabled-but-unused modules are dormant risk. Enumerate them periodically and disable what no longer earns its place.
  • Watch the seams. The call path here ran through a public keeper and a public mempool. Behavioral monitoring on module entry points — who calls them, with what calldata — catches abuse before the unwind, not after.

Two uncomfortable footnotes

First, the MEV bot that front-ran the attack is not a recovery mechanism. Yoink paid roughly $47,000 to capture $7.8 million in tokens, and the bot operator is under no obligation to return them. That the attacker was deprived of the proceeds is a curiosity of public mempool mechanics, not a control. Protocols and users who treat searcher greed as a backstop are mispricing the risk.

Second, the freeze that currently immobilizes the funds is an issuer-level restriction on rsETH transfers, applied by Kelp DAO to the receiving address. It worked here, and holders of the drained position should be grateful it did. But it is worth stating plainly: the ability of a token issuer to blacklist an address at the contract level is a centralization lever, and its existence is a security property of the token that users should weigh knowingly rather than discover mid-incident.

The core lesson stands regardless: in 2026, the most dangerous vulnerability in a well-built multisig is usually the least-examined contract it has chosen to trust.

TrustGrade tracks the security posture of protocols, wallets and infrastructure providers. Verified registry scores and security scans arrive with TrustGrade Code Scoring in December 2026.