A Leaked Approval Drains $7.5M From the jaredfromsubway MEV Bot

An attacker drained about $7.5 million from jaredfromsubway.eth, one of Ethereum's best-known MEV bots, in a theft disclosed on June 22. The bot's trading code was not defeated and its keys were not stolen. Instead the attacker used token permissions the bot had already granted, standing approvals to helper contracts under the attacker's control that were never withdrawn once the interactions that created them were over. Fake liquidity pools built around counterfeit tokens, listed as fWETH, fUSDC, fUSDT and fCAP, served as the bait that produced those approvals. After the loss, the bot offered a white-hat bounty of 2,150 ETH for the return of the remainder.

The Target: A Bot That Earns From the Order of Transactions

An MEV bot is an automated trader built to capture maximal extractable value, the profit available to whoever influences the order in which transactions land in a block. That work takes the form of arbitrage between pools, liquidations, and trades placed around other users' pending swaps, and it is decided in milliseconds, with no human in the loop. Bots of this class therefore carry working inventory in many tokens, touch a large number of contracts, and engage with newly created pools almost as soon as those appear, all of it inside the Ethereum infrastructure most on-chain activity passes through without users ever addressing it directly.

The Mechanism: An Approval That Outlived Its Purpose

An ERC-20 approval is the permission slip of Ethereum token transfers. Because a token contract, not the wallet, holds the ledger of balances, any contract that needs to move a user's tokens must first be granted an allowance by that user, after which it can pull up to that amount at any time until the allowance is revoked. Approvals are routinely set to unlimited so that a trading system does not pay gas for a fresh approval before every transaction, and nothing expires them on its own. An approval that remains in force after the trade that required it has settled is a dangling approval, and it is indistinguishable, from the token contract's point of view, from one granted a second ago.

That is the opening the attacker worked. The counterfeit fWETH, fUSDC, fUSDT and fCAP pools existed to be traded against, and interacting with them routed the bot through helper contracts the attacker controlled, each of which came away holding an allowance over real assets. The bait did not need to be profitable for long; it only needed to be touched. Once the approvals existed, no further deception was required, because the attacker's contracts simply exercised a permission the bot had signed for, and the token contracts honored it exactly as designed. Roughly $7.5 million moved out on that basis.

The Response: 2,150 ETH Offered for the Rest

The bot's operator answered with a white-hat bounty of 2,150 ETH, the now-conventional offer in which a victim proposes that the attacker keep a defined share and return the balance, usually with an implied end to any further pursuit. Such offers succeed unevenly. They work best when the attacker's addresses are already tagged, when the assets are hard to launder, and when the sum on the table is large enough to beat the discount a thief accepts to move funds through mixers or bridges. No response to the offer had been made public as of the disclosure on June 22.

What Is Unresolved: Permissions Nobody Audits

The loss fits the pattern of a month in which several of the largest losses came from operational failures rather than flaws in contract code, the clearest case being Humanity Protocol's drain on June 9 after multisig keys meant for separate holders ended up on one machine. PeckShield counted $75.87 million stolen across 40 incidents in June, down 7.13% from May's $81.7 million, so the aggregate was flat to slightly improved even as individual failures grew more mundane. The open question for automated traders is procedural rather than technical: whether approvals are inventoried and revoked as a matter of routine, and whether a bot that must transact faster than a person can review anything can safely be allowed to grant permissions at all.