🚨 ALERT — Ongoing exploit on Ethereum Startale ERC-7579 smart accounts are being drained account-by-account: ~$2,876 (USDC+USDT) taken from 330 pre-funded counterfactual accounts across 41 self-destruct-constructor batches, still ongoing. No capital, no signatures — the attacker deploys each victim account and hijacks it in the very same transaction. Root cause: StartaleSmartAccount.initializeAccount(bytes) hands control to an attacker-supplied `bootstrap` via delegatecall (arbitrary code in the account's context). For external callers it's gated ONLY by a TRANSIENT-storage flag set in AccountProxy's constructor (setInitializable → TSTORE). But transient storage lives for the WHOLE transaction, not just the constructor — so after the factory's createAccount() deploys+initializes an account, the flag is still set, and anyone can call initializeAccount AGAIN in the same tx to re-init with a malicious bootstrap and sweep it. Any funds parked at a not-yet-deployed Startale account address are at risk. Flow (per victim, in one constructor): factitData, salt=0) deploys the account at itsfunded address (sets the transient init flag) → attacker calls initializeAccount(evilBootstrap) on the fresh account (flag still live) → delegatecall rur) → ×330 accounts → drained. Attack tx (example): etherscan.io/tx/0x1a021a27c8… Attackers: 0x901dafde7057bc2478d1ef640fb5515ea4757aab · 0x91138476a3fde4bf69c253c134b1647377348b5b Vulnerable: StartaleSmartAccount 0x000000b8f5f723a680d3d7ee624fe0bc84a6e05a + StartaleAccountFactory 0x0000003b3e7b530b4f981ae80d9350392defef90 Subscribe to our TG bot for real-time attack alerts 👉 exvul.com/skyeye-monitor

🚨SlowMist TI Alert🚨 💸 @likwid_fi Loss: 74.31 BNB 🔍 Root Cause: LikwidMarginPosition._executeAddCollateralAndBorrow (leverage=0 branch) never assigns delta.pairDelta, so the borrow path leaves pairReserves untouched. getAmountOut(pairReserves,...) returns the same 4.7857 BNB quote on every call — the attacker repeated the margin/borrow cycle 14 times, settling 211.8M TOKEN at the first-trade marginal price with no AMM price impact. 📌 Attacker EOA: 0x90bde1e0bb16b3deeb9d638acf8d01f19fd2f31e 📌 Attack Contract: 0xc63fb27f52ed8d06673c60c3075b2d3bd26cf4aa 📌 Vulnerable Contract: 0x6bec0c1dc4898484b7f094566ddf8bc82ed7abe8 (LikwidMarginPosition) 📌 Victim Contract: 0x065d449ec9d139740343990b7e1cf05fa830e4ba (LikwidVault) Powered by SlowMist.AI Tx: bscscan.com/tx/0x83cbd07d59a…

🚨 ALERT — Exploit on Base The Internet Token ($INT, theinternettoken.com) was hit by an arbitrary-mint exploit: a no-capital attacker minted ~925.4M INT out of thin air, dumped 161.3M into the INT/WETH Uniswap V3 pool to take ALL of its 5.85 WETH, and still holds 764.1M INT — the whole exploit ran inside a one-shot contract's constructor. Root cause: LiquidityUnifier — a contract allowed to mint INT — exposes a permissionless swapV3(token, pool) with a CALLER-SUPPLIED pool. Validation only checks that the pool has code, isn't on the excluded list, and that its token0()/token1() return INT and `token` — all trivially faked. swapV3 sets currentPoolV3 = pool and calls pool.swap(); The fake pool calls back uniswapV3SwapCallback(amount0Delta, …), whose only check is msg.sender == currentPoolV3, and which then does RewardToken.mint(currentPoolV3, amount) with an attacker-chosen amount. The one guard, validateSupply ("supply cannot increase" across the call), was sidestepped by converting the freshly minted INT through the project's Convertor inside the call (supply back down) and converting back right after. Attack tx: basescan.org/tx/0xed62bb27bd… Attacker: 0x5f7ce6395818857ac20730dc990f614356d1ec68 Victim (INT token): 0x968d6a288d7b024d5012c0b25d67a889e4e3ec19 Vulnerable LiquidityUnifier: 0x837dbabc4f5fa78baf177597edbda09645822032 The mint path is still open to anyone until LiquidityUnifier's mint rights are revoked — do not buy or LP $INT. Subscribe to our TG bot for real-time attack alerts 👉 exvul.com/skyeye-monitor