The MEV attack that drained 15 million thanks to false ERC-20 approvals

A sophisticated attack on the MEV bot known as JaredFromSubway left a hole of approximately $15 million after a malicious actor exploited the logic that the bot uses to detect trading opportunities. Instead of forcing a direct technical failure, the attacker created fake swimming pools and tokens which appeared to be cost-effective and got the automated system to grant ERC-20 permits to "helper" contracts controlled by the attacker.

The modus operandi was not noisy: the first movements seemed to be harmless evidence aimed at confirming how the bot reacted to certain exchange routes, and only later were the routes changed to make the approvals intact and unconsumed. This behaviour allowed to accumulate valid spending permits - up to more than 92 WETH in approvals - which were finally used to execute transfers via transfer and emptying assets such as WETH, USDC and USDT from the boot contract.

This incident shows two truths difficult to ignore in the DeFi ecosystem: on the one hand, that MEV bots are powerful tools but also attractive attack surfaces; on the other, that tokens approvals are a critical risk vector when delegated to unaudited contracts. JaredFromSubway, a private operation famous for "sandwich" attacks, has publicly reacted and offered rewards to try to recover funds, although negotiations with alleged white hits and partial return remain uncertain. The public thread published by JaredFromSubway and Blockaid's initial network notice are available for viewing the communiqués and the official timeline: Blockaid and JaredFromSubway.

From a technical perspective, the failure is not so much a vulnerability in the ERC-20 standard as a bad trust-control architecture: the bot trusted the apparent profitability of on-chain routes without validating the authenticity and safety of the counterparties and contracts involved. MEV bots operate with minimum latences and automated decisions, making them vulnerable to deception that replicate legitimate signals. To reduce this risk, solutions such as sending transactions by private relays or using infrastructures that avoid public exposure of the mempool can help; community and bots operators already use alternatives such as Flashbots to mitigate certain types of value extraction in the mempool ( Flashbots).

The implications for DeFi projects and operators are clear: the approvals must be of minimum privilege and under human or multisig control, not implicit properties of automated flow. Practical recommendations include implementing time spending limits, using contracts that require multilateral confirmation to approve significant amounts, auditing and marking helper contracts through on-chain white lists, and separating the opportunity detection logic from the final execution of funds. Also, simulating and testing routes with replay environments (Tenderly, Hardhat, mempool simulators) and static analysis tools before giving permission to any contract reduces the risk of interaction with malicious code.

For security officials and developers, it is also essential to implement real-time alerts about unusual changes in the properties and the tokens balance, and to maintain rapid response processes that allow for the revocation of permits or the movement of funds to safe custody contracts. Private key management and the separation of operational roles (analysis, signature, execution) minimize the possibility that a single automated routine can approve and lose funds without human supervision.

Beyond technical measures, the incident raises questions about governance and ethics in MEV: private operations with the capacity to run sandwich attacks generate externalities in the trading experience of retail users, and a failure that results in millions of stolen dollars increases regulatory and community pressure on these actors. The balance between market innovation and operational responsibility must be directed towards more demanding safety standards if the model wants to be sustained on a large scale.

Finally, this attack is a wake-up call for any actor that automates financial decisions on-chain: speed does not replace diligence. Auditing each layer, limiting privileges, using private relays where appropriate and maintaining human and multisig processes for significant movements are practical that, combined, reduce the likelihood that a similar explosion can be repeated.