Bug de aprobación en Sushi RouteProcessor2

El 9 de abril de 2023, SushiSwap lanzó suavemente un nuevo contrato de router — RouteProcessor2 — para impulsar su interfaz de swaps v3. En cuestión de horas, el equipo de seguridad HYDN había identificado un bug crítico de control de acceso. En cuestión de minutos tras esa divulgación, los bots MEV monitorizando la mempool pública adelantaron el rescate del white-hat y drenaron aproximadamente $3,3 millones en WETH de usuarios que habían concedido aprobaciones de tokens al nuevo router.

Qué ocurrió

RouteProcessor2 enrutaba swaps de múltiples saltos y requería que los usuarios concedieran aprobaciones estándar de tokens ERC-20 al contrato del router — la UX normal de agregadores DEX. Dentro del router, una ruta de ejecución de swap llamaba a una función sin permisos que no validaba que el llamante del swap coincidiera con el beneficiario del swap. Cualquier dirección podía iniciar un swap que consumiera la asignación aprobada de tokens de una víctima y redirigiera la salida al atacante.

El plan white-hat de HYDN era drenar los fondos en riesgo hacia una dirección conocida y segura desde donde pudieran ser devueltos. El plan era sólido pero se ejecutó en la mempool pública: cuando el white-hat envió la primera transacción de rescate, los bots MEV que observaban la mempool replicaron el exploit contra cada aprobación vulnerable restante y se marcharon con la mayor parte del WETH en riesgo — aproximadamente 1.800 WETH (~$3,3M) — en segundos desde que el bug se hizo visible.

Consecuencias

• HYDN, con la autorización de los contribuyentes principales de Sushi, ejecutó contratos de rescate cross-chain que drenaron tanto capital en riesgo restante como fue posible hacia direcciones seguras, y desplegó contratos watcher de front-running para bloquear más explotación por bots.
• La mayoría de los fondos rescatados se devolvieron a los usuarios afectados; los ~$3,3M perdidos ante los bots MEV se recuperaron parcialmente mediante una mezcla de negociación, seguimiento público de direcciones y cooperación de exchanges.
• Sushi deshabilitó RouteProcessor2 y lanzó un router parcheado.
• El incidente ocurrió en el contexto de una citación activa de la SEC contra SushiSwap — la presión legal y de PR del momento fue sustancial.

Por qué importa

El incidente de Sushi es el ejemplo canónico del problema de la mempool pública para operaciones white-hat: cualquier transacción de rescate visible para los bots MEV se convierte en una plantilla gratuita para adversarios con infraestructura más rápida. La mejor práctica desde entonces se ha desplazado hacia la presentación por RPC privado (Flashbots Protect, MEV-Share) para cualquier operación white-hat, y hacia integrar herramientas de coordinación de rescate en el diseño del protocolo (p. ej. pausa + recuperación forzada basada en permit) en lugar de improvisarlo después del incidente.