A long-term MEV bot hunting ordinary traders on Ethereum ultimately fell into a "customized" trap worth $7.5 million.

On June 21, the well-known sandwich arbitrage bot Jaredfromsubway.eth on Ethereum was attacked, with assets like WETH and USDC transferred from the address, resulting in an initial loss estimate of over $7.5 million (though the publicly disclosed loss figures still vary).

Interestingly, this attack involved neither a private key leak nor the exploitation of traditional smart contract vulnerabilities, but rather the attacker pre-deployed a large number of fake tokens, liquidity pools, and auxiliary contracts, packaging them into transaction paths that might have arbitrage opportunities, luring the bot into granting ERC-20 Approval to malicious contracts during automated execution, ultimately allowing the assets of the MEV bot to be "legally" taken away.

At the time of writing, Jaredfromsubway.eth has publicly called out to the attacker via on-chain messages, stating that "if 2,150 Ether is returned within 48 hours, a 50% white hat bounty will be offered, otherwise all feasible legal and enforcement means will be pursued for accountability."

However, even a highly specialized code-driven MEV bot can stumble over Approvals, prompting a reassessment of just how dangerous this "Approval" action we use daily might be.

1. A Reverse Hunt Specifically Designed for MEV Bots

Upon a serious review of this attack incident, it becomes clear that this was not a randomly triggered vulnerability, but rather a long-term hunt targeting the trading logic of Jaredfromsubway.eth.

Jaredfromsubway.eth has been one of the most recognized sandwich arbitrage bots on Ethereum. A sandwich attack, simply put, occurs when a bot detects an impending on-chain transaction, preemptively buys before the user, driving up the price; after the user completes the transaction at a worse price, it immediately sells, profiting from the price difference.

Consequently, this strategy requires the bot to continuously scan on-chain transactions, quickly assessing arbitrage opportunities and organizing transaction paths to invoke different tokens and contracts, which also means the faster it is and the more assets and protocols it covers, the more opportunities the bot can capture.

However, this very characteristic became the breakthrough point for the attack.

In retrospect, the attacker did not directly target the bot's capital contracts but instead spent weeks constructing a seemingly profitable trading environment:

• The first step was to deploy a large number of fake tokens and liquidity pools. These tokens mimicked common assets like WETH, USDC, USDT in name, interface, and trading behavior, leading the bot's automatic recognition system to mistakenly believe it had found a normal trading path;
• The second step was to gradually gain the bot's trust. In early tests, approvals granted by the bot were utilized normally; once the bot’s system began to repeat similar paths, the attacker adjusted the contract logic to leave some of the approvals generated by the bot unconsumed and not reset after the transaction finished, allowing these approvals to persist;
• Finally, the attacker concentrated on invoking the still valid approval limits, transferring real WETH, USDC, and USDT from the bot's contract;

In essence, the entire attack was precisely aimed at the operational characteristics of MEV bots, first creating an environment that conformed to their profit-predicting rules, and then leveraging their mechanism for pursuing automated transaction paths to make the system voluntarily relinquish asset invocation rights.

This also explains why even highly specialized MEV bots can fall victim.

They know how to calculate price differences, gas costs, and transaction orders, but may not adequately authenticate every newly appeared contract. From this perspective, the ordinary user's problem is "clicking confirm without understanding," while the automated bot's problem is "executing automatically without confirming."

On the surface, the two seem entirely different, yet the underlying risks are quite similar, as they both treat authorization as a routine step before completing a transaction, failing to clearly recognize the high risks hidden within.

2. Why is Approval Often Underestimated?

It is well-known that in the ERC-20 standard of Ethereum and EVM-compatible chains, Approval is a fairly fundamental design.

However, when users directly transfer in their wallets, they usually call transfer and generally do not involve Approve; only in scenarios of DEX, lending, staking, or adding liquidity, do users need to allow the smart contract to invoke tokens, which involves Approval.

For example, when we want to swap USDT for ETH on Uniswap, the Uniswap smart contract cannot directly take USDT from your wallet; it must first execute an Approve to inform the system "I authorize Uniswap to withdraw X amount of USDT from my wallet."

Once the authorization is complete, the contract that obtains permission can use transferFrom to invoke the user's USDT within the limited amount, thus facilitating the subsequent swap.

In other words, the Approval itself is not a flaw; it is the essential basis for DeFi to operate normally. The issue is somewhat similar to the automatic deduction permissions in Alipay/WeChat:

Users do not hand over their account passwords to the merchant, but allow the merchant to withdraw within an agreed range. As long as the authorization remains valid, subsequent deductions do not require users to re-enter passwords or confirm each transaction, which inherently brings some problems.

First is the issue of unlimited authorization; people often convert a single transaction into a long-term permission. Primarily to reduce the operations and gas costs incurred from repeated authorizations, many DApps will default to claim a very large authorization limit, often referred to as "unlimited authorization."

A user might only want to complete a transaction with 100 USDC but allows the contract to potentially use all USDC in their address in the future. As long as this authorization is not revoked, even if the user currently has only a small amount of assets in their wallet, any future USDC transferred back in could still be affected.

Secondly, authorizations by default do not disappear when leaving a DApp. Many users confuse "disconnecting wallet" with "revoking authorization"; in reality, disconnecting just makes the webpage unable to read or request the current wallet temporarily and does not alter the Approval already written on the blockchain.

Closing the webpage, deleting the DApp, clearing the browser cache, or even switching wallet applications will not make it automatically invalid.

Finally, even normal contracts can become dangerous in the future. Many authorization risks do not originate solely from initially malicious phishing sites, much like this hunt; users may grant permissions to a protocol that was normal at the time, but afterward, the protocol's contract could be attacked, the admin key leaked, upgrade logic replaced, or issues arise with its invoked routing contracts.

From the user's perspective, assets remain in their address, but from the perspective of permissions, another contract continually possesses the ability to invoke those assets. Thus, the Approval risk isn't only "Did I authorize a bad actor?", but also "Will the entity I authorized encounter issues in the future?".

3. How to Manage Approval Risks

In the face of Approval risks, the simplest suggestion is "Do not grant unlimited authorization."

However, in the real DeFi environment, outright refusal of authorization is not realistic; as mentioned earlier, authorization itself is not a flaw, it is the foundational method for on-chain applications to invoke assets.

What truly needs to change is transforming Approval from a one-time confirmation action into a continuous permission management mechanism.

For ordinary users, several fundamental habits need to be established:

• First, follow the "least privilege" principle. When a wallet prompts for authorization, try to set limits based on the actual needs of the interaction. For instance, if planning to use 100 USDT, only authorize close to 100 USDT instead of setting unlimited permissions;
• Second, distinguish between storage wallets and interaction wallets. Addresses that store large assets long-term should avoid frequent connections to unfamiliar DApps; for participating in airdrops, minting, new projects, and high-risk DeFi interactions, a separate address can be used to limit potential losses;
• Third, regularly check and revoke unnecessary authorizations. Users can use tools like Revoke.cash or enter the corresponding token page in imToken, clicking the lower left corner "Token Function," then selecting "Authorization Management" to view the authorized objects, tokens, and limits for that address, and initiate revocations for permissions no longer used or whose origins are unclear (further reading "A guide to using Revoke.cash for authorization management");

Of course, despite the thousand words spoken, depending solely on users' security awareness and regular checks is still insufficient against the ever-elusive authorization attacks; after all, most users find it challenging to discern to whom a string of contract addresses belongs and to judge whether a specific authorization limit is reasonable.

Thus, as the first line of defense for users entering Web3, wallets must provide proactive defenses in their product capabilities.

Taking imToken as an example, it marks or intercepts recognized risk tokens, addresses, and DApps, providing targeted risk alerts when users grant token permissions to ordinary external accounts or directly transfer to contract addresses, these alerts cannot replace user judgment, but at least can add a necessary safety buffer before actual signatures.

Additionally, imToken also conducts structured parsing and readable presentation of the signed content at critical stages like DApp login, transfers, token exchanges, and approvals, helping users understand what they are agreeing to before confirming, ensuring the content users sign aligns with the actions they see, rather than being compressed into an indistinguishable hash.

With the further advancement of Clear Signing standards like ERC-7730, this "What You See Is What You Sign" readable presentation is expected to gradually transform from the product capabilities of individual wallets into a shared industry standard among wallets, DApps, and smart contracts.

Overall, private keys determine who owns the account, while Approval determines who can still invoke assets within the account; both are not the same thing but are equally important.

This also signifies that wallet security cannot be limited to "has the private key been leaked," and it requires joint efforts from users to wallets: users need to clearly understand the entities and limits before authorizing, and promptly clean up unnecessary permissions after interactions; for wallets, it is necessary to make these permissions, which are originally hidden in contracts, more visible, comprehensible, and easier to restrict and revoke.

After all, the most dangerous might not be that transaction just executed, but an authorization long forgotten yet still valid.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。