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

An attacker pulled about $7.5 million out of jaredfromsubway.eth, one of Ethereum's best-known MEV bots, in a theft disclosed on June 22. The trading code was not beaten. The keys were not stolen. What the attacker used were token permissions the bot itself had granted: standing approvals to helper contracts under the attacker's control, never withdrawn once the interactions that created them were over. The bait was a set of fake liquidity pools built on counterfeit tokens listed as fWETH, fUSDC, fUSDT and fCAP. After the loss, the bot's operator put up a white-hat bounty of 2,150 ETH for the return of the remainder.

A bot paid by transaction order

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. The work is arbitrage between pools, liquidations and trades placed around other users' pending swaps, decided in milliseconds with no human in the loop. A bot of this class carries working inventory in many tokens, touches a long list of contracts, and trades against newly created pools almost as soon as they appear, all of it inside the Ethereum infrastructure most on-chain activity passes through without users ever addressing it directly.

An approval that outlived its purpose

An ERC-20 approval is the permission slip of Ethereum token transfers. Because the 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, and it can then pull up to that amount at any time until the allowance is revoked. Approvals are routinely set to unlimited so a trading system does not pay gas for a fresh one before every transaction, and nothing expires them on its own. An approval still in force after its trade has settled is a dangling approval. Seen from the token contract, it is indistinguishable from one granted a second ago.

That was 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 stay profitable. It only needed to be touched. Once the approvals existed, no further deception was involved: the attacker's contracts 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.

2,150 ETH on the table

The 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 tend to work when the attacker's addresses are already tagged and the assets are hard to launder, and when the sum on the table beats the discount a thief accepts to push funds through mixers or bridges. No response to the offer had been made public as of the disclosure on June 22.

The housekeeping question

The loss fits the month it landed in, one where several of the largest losses came from operational failures rather than flaws in contract code. The clearest case was Humanity Protocol, drained 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; set against the $81.7 million it recorded for May, that is a 7.13% decline, an aggregate flat to slightly improved even as the individual failures grew more mundane. For automated traders the open question is procedural, not technical: whether approvals are inventoried and revoked as a matter of routine, and whether a bot that must transact faster than any person can review should be trusted to grant permissions at all.