On the morning of September 15, an Ethereum user discovered their multisig wallet had been silently gutted. Approximately $7.73 million in rsETH — a liquid restaking token — was gone, drained through a pair of transactions that security monitors flagged but could not stop in time. The mechanism was surgical: a malicious module embedded in the victim's Safe wallet combined with a weaponized Uniswap V4 hook to funnel funds into an attacker-controlled liquidity pool. The incident is a sobering case study in how composability — DeFi's greatest feature — can be turned against the very users it is meant to empower.
How the Attack Unfolded
Safe wallets, formerly known as Gnosis Safe, are widely regarded as among the most battle-tested multisig solutions in the Ethereum ecosystem. Their modular architecture allows teams to attach custom execution logic — automating treasury operations, enforcing spending policies, or integrating protocol-specific functions. That flexibility, in this case, became the attack surface. Security monitoring identified exactly two transactions that were responsible for the entire $7.73 million loss, suggesting the attacker had prepared the exploit environment well in advance and executed it with minimal on-chain footprint.
The attack chain appears to have run as follows: a malicious module — either installed fraudulently or present as a compromised legitimate plugin — invoked an execution path within the Safe contract that bypassed the standard multisig approval flow. This allowed the attacker to initiate asset movements without triggering the wallet's normal signature thresholds. The redirected rsETH was then routed through a Uniswap V4 liquidity pool that the attacker controlled, with a custom hook — one of Uniswap V4's defining architectural innovations — used to intercept and siphon the tokens at the pool level.
Uniswap V4 Hooks: Power With a Price
Uniswap V4's hook system was introduced to give developers granular control over liquidity pool behavior. Hooks are smart contracts that execute at defined lifecycle points — before a swap, after a swap, when liquidity is added or removed — and they enable sophisticated market-making logic, dynamic fee structures, and on-chain order books. They also, as this incident illustrates, can be authored by anyone and deployed as traps. An attacker who controls both the pool and its hook has effectively built a roach motel: assets enter via an ostensibly routine swap or liquidity operation, and they do not come out.
This is not a vulnerability in Uniswap V4's code per se. The protocol is functioning exactly as designed. The problem is that the trust model for hooks is entirely permissionless — any address can deploy a hook contract, and users interacting with pools that use attacker-authored hooks bear the full risk. When that hook is the final destination for funds redirected by a compromised Safe module, the result is a near-invisible drain that appears, at the transaction level, to be a legitimate DeFi interaction.
The Custom Module Problem
The deeper architectural question raised by this incident is not about Uniswap V4 at all — it is about the Safe module ecosystem. Safe's modular design is one of its most powerful characteristics, enabling everything from automated payroll to complex DAO treasury logic. But each module added to a Safe wallet expands its trust surface. A module with execution rights can, in principle, do anything the wallet's signers can do. If a module is malicious, misconfigured, or later compromised through an upgrade mechanism, the multisig's signature threshold offers no protection whatsoever.
The evidence in this case points to the wallet's custom module configuration as the primary point of failure. Whether the malicious module was introduced through a social engineering attack on one of the wallet's administrators, a supply-chain compromise in a third-party module provider, or a deliberate act by an insider is not yet established from the available information. What is clear is that once the module had execution rights, the attacker needed only two transactions to extract $7.73 million in rsETH and launder it through the hook-equipped Uniswap V4 pool.
What This Means for DeFi Security
For institutional and high-net-worth DeFi participants who rely on Safe wallets, this attack should trigger an immediate audit of installed modules. Any module with unrestricted execution rights deserves scrutiny equivalent to that applied to a full wallet signatory. Time-locked execution delays, module-specific spending caps, and independent security reviews of third-party plugins are not optional hygiene for wallets holding seven-figure sums — they are baseline requirements.
The Uniswap V4 hook dimension adds a second layer of due diligence. Protocols and aggregators routing transactions through V4 pools should display clear provenance information about the hooks attached to those pools. Users should be able to verify, at interaction time, whether a hook is audited, open-source, and operated by a known entity. Without that transparency layer, V4's permissionless hook architecture is a persistent vector for exactly this type of end-of-pipe asset capture.
The $7.73 million rsETH loss on September 15 is not a catastrophic systemic failure — no protocol was broken, no chain was halted. But it is a precise and instructive demonstration of how legitimate infrastructure, when composed by an adversary rather than a builder, can be turned into an extraction machine. The underlying technology worked as designed. The security model around it did not.
Written by the editorial team — independent journalism powered by Bitcoin News.