Startale exploit analysis

Startale's ERC-7579 smart account factory on Ethereum was drained across an ongoing campaign starting on 2026-09-16, where the attacker deployed a throwaway contract from EOA 0x901DafdE7057BC2478d1eF640fb5515EA4757AAB and re-initialized counterfactual accounts that users had pre-funded at their predicted CREATE addresses (example attack transaction, block 25987506). DeFiHackLabs reconstructs the drain on a mainnet fork and confirms the persistence of the init flag past the constructor.

AccountProxy's constructor calls Initializable.setInitializable() (a TSTORE on the INIT_SLOT) and then upgradeToAndCall(impl, initializeAccount(initData)). The StartaleSmartAccount.initializeAccount(bytes) function gates external callers with Initializable.requireInitializable() alone: it performs no "already initialized" guard, and runs the user-supplied bootstrap via DELEGATECALL. The bug is that EIP-1153 transient storage is scoped to the whole transaction, not to the constructor call frame, so the INIT_SLOT flag written by the proxy constructor is not rolled back when the constructor returns. It stays set for the remainder of the tx, so any external caller can subsequently call initializeAccount on the just-deployed account with a malicious bootstrap, which runs in the account's own context via DELEGATECALL and drains any pre-funded balance.

In the example tx, the factory deployed 40 accounts in its constructor (legitimate user flow), then the attacker called initializeAccount a second time on 23 of the pre-funded ones with a malicious bootstrap that swept their USDC into a single collector. DeFiHackLabs records 427.551160 USDC drained in that one tx, with 32.555561 USDC reproduced across a 3-account subset; the wider campaign aggregate is ~$2,876 in USDC+USDT across 41 known batches.

The fix is an initializer modifier that flips a permanent storage flag on first successful init, in addition to the transient guard.