O ataque MEV que drenou 15 milhões graças a aprovações ERC-20 falsas

Um ataque sofisticado contra o bot MEV conhecido como JaredFromSubway deixou um buraco de aproximadamente 15 milhões de dólares depois de um ator malicioso explorar a lógica que o bot usa para detectar oportunidades de trading. Em vez de forçar uma falha técnica direta, o atacante criou piscinas e tokens falsos que aparentavam ser rentáveis e conseguiram que o sistema automatizado concedesse licenças ERC-20 a contratos “helper” controlados pelo atacante.

O modus operandi não foi barulhento: os primeiros movimentos pareciam provas inofensivas orientadas a confirmar como reageva o bot ante determinadas rotas de troca, e só depois se modificaram as rotas para que as aprobações ficassem intactas e sem se consumir. Esse comportamento permitiu acumular licenças de despesa válidas — até mais de 92 WETH em aprobações — que foram finalmente usadas para executar transferências via transferFrom e esvaziar ativos como WETH, USDC e USDT desde o contrato do bot.

Este incidente mostra duas verdades difíceis de ignorar no ecossistema DeFi: por um lado, que os bots MEV são ferramentas poderosas, mas também superfícies de ataque atraentes; por outro, que as aprobações de tokens são um vetor de risco crítico quando se delegam a contratos não auditados. JaredFromSubway, uma operação privada célebre por ataques de tipo “sandwich”, reagiu publicamente e ofereceu recompensas para tentar recuperar fundos, embora as negociações com supostos white hats e a devolução parcial permaneçam incertas. Para ver os comunicados e a linha temporal oficial, você pode consultar o tópico público publicado por JaredFromSubway e o aviso inicial do Blockaid em redes: Blockaid e JaredFromSubway.

De uma perspectiva técnica, a falha não é tanto uma vulnerabilidade no padrão ERC-20 como uma má arquitetura de controle de confiança: o bot confiou na aparente rentabilidade de rotas on-chain sem validar a autenticidade e segurança dos contrapartes e contratos envolvidos. MEV bots operam com latências mínimas e decisões automatizadas, o que os torna vulneráveis a enganos que replicam sinais legítimos. Para reduzir este risco, soluções como enviar transações por relays privados ou usar infra-estruturas que evitem a exposição pública do mempool podem ajudar; a comunidade e operadores de bots já empregam alternativas como Flashbots para mitigar certos tipos de extração de valor na mempool ( Flashbots).

As implicações para projetos e operadores DeFi são claras: as aprovações devem ser de mínimo privilégio e sob controle humano ou multisig, não propriedades implícitas do fluxo automatizado. Recomendações práticas incluem a implementação de limites de despesas temporárias, a utilização de contratos que necessitem de confirmação multilateral para a aprovação de quantidades significativas, auditar e marcar helper contracts por listas brancas on-chain e a separação da lógica de detecção de oportunidades de execução final de fundos. Além disso, simular e testar rotas com ambientes de replay (Tenderly, Hardhat, simuladores de mempool) e ferramentas de análise estática antes de dar permissão a qualquer contrato reduz o risco de interação com código malicioso.

Para os responsáveis pela segurança e pelos desenvolvedores, também é essencial instruir alertas em tempo real sobre mudanças incomuns em allowances e no balanço de tokens, e manter processos de resposta rápidos que permitam revogar licenças ou mover fundos para contratos de custódia seguros. A gestão de chaves privadas e a separação de papéis operacionais (análise, assinatura, execução) minimizam a possibilidade de uma única rotina automatizada poder aprovar e perder fundos sem supervisão humana.

Além de medidas técnicas, o incidente levanta questões sobre governança e ética em MEV: operações privadas com capacidade para executar sandwich attacks geram externalidades na experiência de trading de usuários retalhistas, e uma falha que resulta em milhões de dólares roubados aumenta a pressão regulatória e comunitária sobre esses atores. O equilíbrio entre a inovação de mercado e a responsabilidade operacional deve ser inclinado a padrões de segurança mais exigentes se o modelo quiser sustentar-se em larga escala.

Finalmente, este ataque é uma chamada de atenção para qualquer ator que automatice decisões financeiras on-chain: a velocidade não substitui a diligência. Auditar cada camada, limitar privilégios, usar relays privados quando adequado e manter processos humanos e multisig para movimentos significativos são práticas que, combinadas, reduzem a probabilidade de um exploit similar poder ser repetido.