JaredFromSubway just lost $7.5M to a token permission nobody revoked. The contract code was fine. That's the catch.
The most active automated trader on Ethereum wasn't hacked through its code. It was drained through a permission it left open, and that attack class works on every contract holding real money.

CryptoVibe Desk · mev · ethereum · smart-contracts

- →JaredFromSubway, one of Ethereum's most active MEV bots, lost an estimated $7.5M today when an attacker used old token approvals to pull funds directly from the contract.
- →The attack used residual token permissions to drain the contract without touching its core logic, a vulnerability that grows in danger with however much capital the bot holds in-contract.
- →Watch for other MEV bots revoking stale approvals on Ethereum in the next 72 hours, which would confirm operators are treating this as a live attack template and not a one-off.
- MEV bot → An automated program on Ethereum that profits by choosing when and where to place its own transactions around other users' trades.
- ERC-20 approval → A permission stored on-chain that lets a specific address move your tokens on your behalf, up to a set limit you authorized.
- transferFrom → An ERC-20 function that an approved address can call to pull tokens out of a contract without the contract's owner doing anything.
- approval trap → An attack that uses pre-existing or attacker-planted token permissions to drain funds without ever touching the contract's core logic.
JaredFromSubway just lost an estimated $7.5M this morning, per crypto.news. The attacker didn't exploit the contract logic. They used a token approval to call transferFrom and pull the funds out.
This is an approval-trap exploit. In ERC-20, an approval grants an external address permission to move tokens on your behalf up to a set limit. If a contract carries stale approvals, or if an attacker can plant one, no exploit of the core logic is needed. The attacker calls transferFrom. The contract complies.
At the contract level, this is a cache invalidation problem. Old state that should have been cleared is still live. Reentrancy protections don't help here. Flash loan defenses don't help. The attack surface is the approval ledger, and the ledger doesn't expire on its own.
JaredFromSubway runs continuously and processes hundreds of transactions per block. The crypto.news report cites working balances of WETH, USDC, and USDT in-contract. That profile means approvals accumulate fast. The capital base grows. The approval state quietly grows with it.
If you're running any automated contract that holds working capital, check your approval state. The MEV security community has treated approval hygiene as theoretical for years. Today it's officially $7.5M of evidence that it isn't.
JaredFromSubway's operator keeping the attack transaction hash and approval chain private while other high-balance bots carry the same exposure is the wrong call. That data is already on-chain. Keeping it private protects no one except the next attacker who reads it first.
Any Ethereum MEV bot with a working balance over $1M that publicly revokes or bounds its ERC-20 approvals on-chain in the next 72 hours, confirming operators are mapping exposure rather than waiting for the next drain.
Primary links and supporting reads used by the desk for this story.
Forward this.











