El ataque MEV que drenó 15 millones gracias a aprobaciones ERC-20 falsas

Un sofisticado ataque contra el bot MEV conocido como JaredFromSubway dejó un agujero de aproximadamente 15 millones de dólares después de que un actor malicioso explotara la lógica que el bot usa para detectar oportunidades de trading. En lugar de forzar un fallo técnico directo, el atacante creó piscinas y tokens falsos que aparentaban ser rentables y lograron que el sistema automatizado otorgara permisos ERC‑20 a contratos “helper” controlados por el atacante.

El modus operandi no fue ruidoso: los primeros movimientos parecían pruebas inofensivas orientadas a confirmar cómo reaccionaba el bot ante determinadas rutas de intercambio, y solo después se modificaron las rutas para que las aprobaciones quedaran intactas y sin consumirse. Ese comportamiento permitió acumular permisos de gasto válidos —hasta más de 92 WETH en aprobaciones—, que finalmente fueron usados para ejecutar transferencias vía transferFrom y vaciar activos como WETH, USDC y USDT desde el contrato del bot.

Este incidente muestra dos verdades difíciles de ignorar en el ecosistema DeFi: por un lado, que los bots MEV son herramientas poderosas pero también superficies de ataque atractivas; por otro, que las aprobaciones de tokens son un vector de riesgo crítico cuando se delegan a contratos no auditados. JaredFromSubway, una operación privada célebre por ataques de tipo “sandwich”, ha reaccionado públicamente y ofreció recompensas para intentar recuperar fondos, aunque las negociaciones con supuestos white hats y la devolución parcial permanecen inciertas. Para ver los comunicados y la línea temporal oficial, puede consultarse el hilo público publicado por JaredFromSubway y el aviso inicial de Blockaid en redes: Blockaid y JaredFromSubway.

Desde una perspectiva técnica, el fallo no es tanto una vulnerabilidad en el estándar ERC‑20 como una mala arquitectura de control de confianza: el bot confió en la aparente rentabilidad de rutas on‑chain sin validar la autenticidad y seguridad de los contrapartes y contratos implicados. MEV bots operan con latencias mínimas y decisiones automatizadas, lo que los hace vulnerables a engaños que replican señales legítimas. Para reducir este riesgo, soluciones como enviar transacciones por relays privados o usar infraestructuras que eviten la exposición pública del mempool pueden ayudar; la comunidad y operadores de bots ya emplean alternativas como Flashbots para mitigar ciertos tipos de extracción de valor en la mempool (Flashbots).

Las implicaciones para proyectos y operadores DeFi son claras: las aprobaciones deben ser de mínimo privilegio y bajo control humano o multisig, no propiedades implícitas del flujo automatizado. Recomendaciones prácticas incluyen implementar límites de gasto temporales, usar contratos que requieran confirmación multilateral para aprobar cantidades significativas, auditar y marcar helper contracts mediante listas blancas on‑chain, y separar la lógica de detección de oportunidades de la ejecución final de fondos. Asimismo, simular y testear rutas con entornos de replay (Tenderly, Hardhat, simuladores de mempool) y herramientas de análisis estático antes de dar permiso a cualquier contrato reduce el riesgo de interacción con código malicioso.

Para los responsables de seguridad y desarrolladores, también es esencial instrumentar alertas en tiempo real sobre cambios inusuales en allowances y en el balance de tokens, y mantener procesos de respuesta rápidos que permitan revocar permisos o mover fondos a contratos de custodia seguros. La gestión de llaves privadas y la separación de roles operativos (análisis, firma, ejecución) minimizan la posibilidad de que una sola rutina automatizada pueda aprobar y perder fondos sin supervisión humana.

Más allá de medidas técnicas, el incidente plantea preguntas sobre gobernanza y ética en MEV: operaciones privadas con capacidad para ejecutar sandwich attacks generan externalidades en la experiencia de trading de usuarios minoristas, y un fallo que resulta en millones de dólares robados incrementa la presión regulatoria y comunitaria sobre esos actores. El equilibrio entre innovación de mercado y responsabilidad operativa debe inclinarse hacia estándares de seguridad más exigentes si el modelo quiere sostenerse a gran escala.

Finalmente, este ataque es una llamada de atención para cualquier actor que automatice decisiones financieras on‑chain: la velocidad no reemplaza a la diligencia. Auditar cada capa, limitar privilegios, usar relays privados cuando proceda y mantener procesos humanos y multisig para movimientos significativos son prácticas que, combinadas, reducen la probabilidad de que un exploit similar pueda repetirse.