Attacker drains up to $310K from two Safes through a leverage module the owners switched on

Set the attacker's net of about 114.09 ETH ^[9] against the roughly 1,300 to 1,335 WETH of Aave debt it had to repay first ^[7], and the take is 8.5% to 8.8% of the borrowing it cleared ^[18]. Put the other way, about 11.4 to 11.7 ether of debt sat behind every ether the attacker kept ^[19]. These were thin positions, the kind a module like FlashLoopAdapter is built to assemble ^[5].

The victims' loss is the same gap seen from their side. Their debt was repaid in the same transaction that took their collateral ^[7], so what they lost is the equity between the two. Divide Crypto Briefing's $305K to $310K loss estimate ^[3] by 114.09 ETH ^[9] and you get about $2,670 to $2,720 per ether ^[17]. At that price the dollar figure and the attacker's net are the same sum. The report does not say what ether price it used.

The fault can sit in one of three places. The narrow answer is a single badly written adapter. Post-incident analyses cited by Crypto Briefing found that open() and close() accepted caller-controlled responses without confirming they came from a legitimate Safe ^[10]. According to SlowMist's account, a fake contract posing as Safe authentication got past that check ^[6][2]. The broad answer is Safe's design. A module with broad execution rights inherits the wallet's power, and the multisig's signature requirements do little once the module has been granted a way around them ^[14]. The third answer blames the flash loan for supplying the capital ^[15], though the borrowed WETH only mattered after the adapter had let the wrong caller in ^[10].

I think the narrow answer fits the evidence. The broad one is the counter-thesis that anyone holding leveraged Safe positions should keep in mind anyway. Aave released collateral because debt was repaid, as designed ^[11]. But the owners had given the adapter permission to operate their accounts ^[5], so along its code paths their multisig was protected only by the checks the adapter's authors wrote ^[14]. The narrow answer would be wrong if a later analysis traced the forged authentication past a check in Safe's own contracts. The analyses so far put the failed check inside FlashLoopAdapter ^[10][11].