How the JaredFromSubway MEV Bot Lost $7.5 million without being hacked

On June 20, 2026, the Ethereum-based MEV bot JaredFromSubway lost 4,424 ETH, worth roughly $7.5 million, after falling victim to a sophisticated approval-based attack.

Instead of targeting Ethereum's infrastructure or compromising private keys, the attacker manipulated the bot into interacting with malicious smart contracts. Fake liquidity pools and counterfeit tokens were carefully designed to resemble legitimate arbitrage opportunities. As the bot executed trades, it unknowingly granted token approvals that later allowed the attacker to drain its assets.

The core issue was simple: after each transaction, the bot never verified whether its approvals had actually been used or revoked. Those unused permissions remained active, allowing the attacker to return later and withdraw the bot's WETH, USDC, and USDT holdings.

GetBlock AML Research reconstructed the full attack sequence to understand exactly how the exploit unfolded.

What Is an MEV Bot?

JaredFromSubway is one of Ethereum's best-known MEV (Maximal Extractable Value) bots—automated software that monitors pending blockchain transactions and reorders them to capture profit.

Its primary strategy is the sandwich attack. The bot places one trade immediately before a user's swap and another immediately afterward, profiting from the temporary price movement created by the victim's transaction.

Whenever users submit transactions to decentralized exchanges, those transactions remain visible in Ethereum's mempool before being confirmed. MEV bots continuously scan this pending activity, simulate its market impact, and identify opportunities where executing transactions first can generate virtually risk-free profits.

Why an outdated smart contract was still vulnerable: The $2.2M Aztec Connect exploit

Although Aztec Connect was officially shut down in 2024, some user assets remained locked inside its immutable smart contracts. In June 2026, an attacker exploited a design mismatch between the protocol’s Layer 1 and Layer 2 components, draining roughly $2.2 million in a single transaction.

Читать дальше

Key Addresses

The investigation identified several addresses involved in the exploit.

Supporting Smart Contracts

• 0x81f248ff583d3f8592ea0354a7b8dbe66de40091 — fake token deployment contract.
• 0xEEE172A069f5171b407eBf47e8FCFB637E944ec2 — controller for the fake decentralized exchange.

Examples of Fake Tokens

• Caps
• fCap
• Two separate fake versions of fWETH

These counterfeit assets were designed to imitate wrapped tokens and lure automated trading algorithms.

Building the Trap

To attract MEV bots, the attacker first needed to manufacture convincing arbitrage opportunities.

Several smart contracts were deployed for different purposes:

• one minted fake tokens;
• another coordinated the malicious infrastructure;
• a third created fake liquidity pools;
• a fourth handled token swaps within those pools.

The attacker ultimately deployed 131 counterfeit token contracts.

From the outside, the tokens looked almost identical to legitimate wrapped assets such as WETH and USDC. Users could exchange real tokens for fake ones through a function called wrapTo(), which required granting the contract permission to spend their assets beforehand.

That approval process became the foundation of the exploit.

Initially, everything functioned exactly as expected. While an internal variable called owner_a_0_19 remained inactive, the wrapTo() function executed a normal safeTransferFrom(), transferring tokens and fully consuming each approval. Every transaction appeared legitimate, giving the bot no reason to suspect malicious behavior.

When DAO governance fails: how TOP was taken over and what Tornado Cash has to do with It

The TOP incident shows that taking over a crypto project does not always require hacking smart contracts. In some cases, acquiring enough voting power and exploiting the system exactly as designed can be enough.

Читать дальше

Once the attacker activated owner_a_0_19, however, control shifted to a separate coordination contract. At that point, the contract's behavior changed entirely.

Instead of calling transferFrom(), wrapTo() silently skipped the token transfer altogether.

The approval granted by the bot therefore remained fully valid, even though the transaction itself appeared successful.

Meanwhile, the coordination contract quietly recorded every unused approval, building a growing inventory of permissions that could later be exploited.

At the same time, the attacker manipulated several fake liquidity pools containing WETH–fCAP and fWETH–fCAP trading pairs.

By carefully adjusting pool balances, the attacker created what looked like highly profitable arbitrage opportunities, making the setup irresistible to automated MEV strategies.

Executing the Attack

The attack began at Ethereum block 25354425, when the JaredFromSubway bot interacted with one of the attacker's fake liquidity pools, SwapV2Pair_0x0e97.

From the bot's perspective, the opportunity appeared highly profitable.

Assuming one fWETH was worth one genuine WETH, the pricing across two manipulated pools suggested a risk-free arbitrage path:

fWETH → fCAP → WETH

The first pool contained:

• 0.1 fWETH
• 0.1 fCAP

The second contained:

• 0.086034434021378528 fCAP
• 0.116281374898538093 WETH

The bot calculated that the trade would generate a profit and proceeded automatically.

It first approved 7,391,033,126,027,264 wei of WETH to the malicious contract and called wrapTo(), which issued an equivalent amount of fake wrapped tokens.

Those tokens were then swapped through the prepared liquidity pool. The trade succeeded, and the bot earned approximately 0.00235 WETH. At this stage, everything behaved exactly as expected. Because the malicious approval mechanism had not yet been activated, every approval was consumed normally during execution.

Dozens of GnosisPay Wallets drained: A deep dive into a bold attack

The attacker didn’t hack the wallets directly. Instead, they tricked the security system into approving fraudulent transactions on its own. A flaw in the signature verification mechanism led to losses of approximately $265K.

Читать дальше

Beginning at block 25360428, the attacker repeatedly called markStatusAndTip(), paying small validator tips to ensure these transactions were processed before the MEV bot's own operations. This changed the contract's behavior completely. The wrapTo() function stopped calling transferFrom(). From the bot's perspective, nothing looked unusual. Transactions continued to succeed. Profits kept coming. No errors were generated.

Behind the scenes, however, every approval the bot granted remained fully active instead of being consumed during execution. The attacker quietly accumulated dozens of valid token allowances. As confidence grew, the bot became increasingly aggressive, executing hundreds of transactions through the malicious contracts in pursuit of arbitrage profits.

The attacker only needed to refresh the malicious contract's status about a dozen times before enough active approvals had accumulated.

Once sufficient access had been obtained, the final stage began. At block 25360696, the attacker simultaneously activated 66 previously deployed bait contracts. Sixty of them already possessed valid ERC-20 approvals granted earlier by the bot.

Each contract immediately exercised its remaining allowance and transferred tokens directly from the bot's wallet to attacker-controlled addresses.

The Core Vulnerability

The exploit did not rely on a flaw in Ethereum or the ERC-20 standard. Instead, it exploited a logical assumption inside the trading bot. Every time the bot called wrapTo(), it automatically granted the contract permission to spend its tokens, assuming that permission would immediately be consumed during execution.

GitHub’s darkest stretch yet: developers worldwide put at risk of massive breaches

The Shai-Hulud attack exposed just how dangerous modern software supply chains have become. In a matter of minutes, malicious updates reached the computers of thousands of developers around the world.

Читать дальше

However, the bot never verified whether the approval had actually been used. Nor did it revoke any unused allowance after the trade completed. If a malicious contract intentionally skipped transferFrom(), the approval remained valid indefinitely. That meant the attacker could return hours—or even days—later and freely transfer the bot's assets using permissions it had voluntarily granted. This simple oversight ultimately resulted in the loss of millions of dollars.

Where the Funds Went

The attacker's primary wallet,

0x3e37f4A10d771Ba9dE44b6d301410b1BEdeA65d0,

successfully drained:

• 2,869,812.43 USDC
• 2,032,769.62 USDT
• 1,474 WETH (worth approximately $2.57 million at the time)

The stolen stablecoins were immediately swapped into ETH.

The funds were then distributed across five separate wallets:

Distribution of stolen assets across attacker-controlled wallets. Source: CertiK

In the final stage of the laundering process, the attacker sent 3,000 ETH through Tornado Cash, obscuring the origin of the funds.

An additional 1,422 ETH was swapped for approximately 2.44 million DAI.

At the time of publication, those funds remained at:

0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2