Jon Tetreault

Writing · October 2026

The module was the signer.

On a job site, the lockbox code goes out to the subs. The door opens for whoever has it, and the door can't tell which sub is standing there. Hand the code to one guy who never checks who's behind him, and the lock on the house is only as good as his habits.

On Wednesday afternoon, two Safe multisig wallets on Ethereum lost about 114 ETH between them. Nobody stole a signer's key. Nobody got an owner to sign anything. Each wallet had enabled a helper contract, and the helper did what it was told by the wrong person.

What happened

The helper is called FlashLoopAdapter. Per The Crypto Times, it's a module for running leveraged positions on Aave v3: a Safe deposits collateral, borrows against it, swaps the borrowed asset back into collateral, and repeats. The owners enable the module once so they don't have to sign every step of the loop.

The exploit transaction landed at 15:08 UTC on October 1, in block 26,098,264, according to The Crypto Times. Security firm SlowMist posted its alert about twelve hours later. Metaverse Post and Crypto Briefing describe the same mechanism, and every account I read agrees on the ETH figure, 114.09. The dollar figures differ by outlet. Crypto Briefing puts the combined loss between $305,000 and $310,000.

The mechanism is simple enough to explain in full. SlowMist's analysis, as reported by Metaverse Post, says the module's open() and close() functions make exactly one check before acting: they ask the caller, treated as a Safe, whether this module is enabled on it. In code, ISafe(msg.sender).isModuleEnabled(address(this)). The module asks the caller, "Am I allowed to work for you?" and takes the caller's word for it.

So the attacker deployed a contract that answers yes. That's the whole forgery. It isn't a Safe. It holds nobody's money. It just says yes.

The second piece is the module's swap step. Per the same analysis, it makes a raw call to whatever router address the caller supplies, with whatever calldata the caller supplies. The attacker set the router to a victim's Safe and the calldata to execTransactionFromModule, the function that lets an enabled module push a transaction through a Safe without collecting signatures. The victims had enabled FlashLoopAdapter for real. So each Safe saw a module it trusted, calling a function it was allowed to call, and did what it was asked.

From there it was bookkeeping. Per The Crypto Times, the attacker borrowed 11,537 WETH in a flash loan from Morpho, repaid about 1,335 WETH of the larger Safe's Aave debt, which released about 1,306 weETH of collateral, took the collateral, settled the loan, and kept the difference. The second Safe lost about 6.4 weETH. Gas for the whole thing: $10.55.

Nothing was broken, and that's the point

Aave's pools worked as designed. Safe's contracts worked as designed. The module's permission was granted by the owners, with the threshold of signatures their wallet requires. Crypto Briefing notes that neither Aave v3 nor Safe's core infrastructure was compromised. Every component did its job. The only flaw was in the one component whose job was to check who was asking, and it checked by asking.

Safe's own documentation says it plainly: "Safe Modules can be a security risk since they can execute arbitrary transactions. Only add trusted and audited modules to a Safe. A malicious module can take over a Safe." The reason is the function the attacker used. execTransactionFromModule skips the signers. That's what a module is for: automation without approvals. It is also the entire risk.

A module isn't a feature you add to your wallet. It's a signer you add to your wallet, with a threshold of one.

This isn't the first time this season. Last month the desk at blockchainai.news traced a different leveraged Safe losing about 3,100 aEthrsETH through a different custom module with the same shape: a public entry point that forwarded caller-supplied calldata into the Safe. The owners of that one disabled eleven modules in the hours afterward.

Who built FlashLoopAdapter? None of the reports I read say. The Crypto Times notes that as of its report there was no confirmed patch, no pause, and no compensation plan. I don't know more than that, so I won't say more than that.

What I'd do

  1. List the modules on every Safe you sign for. The Safe's contract will tell you, and so will the wallet app. If the list isn't empty, you have signers you may not have counted.
  2. Treat every module as a sole signer. If you wouldn't hand that team a key with a threshold of one, don't hand its contract module rights. When the strategy is done, disable the module. Removing one takes the same owner threshold as adding one.
  3. Audit the module, not the neighbors. "Built on Aave" and "works with Safe" describe what the module touches, not what it is. The protocols underneath can be perfect and the piece you enabled can still answer yes to anyone.
  4. If FlashLoopAdapter is on your Safe, disable it now. The flaw is in the module's own checks, and nobody has published a fix.

Check who has the lockbox code.

Verify everything, including the helpers you hired to skip the verifying.

— Jon Tetreault, October 2026. The habits, tools, and checks behind this piece are what I teach in Crypto Security Mastery.