Drenaje del oráculo en las DOV heredadas de Ribbon en Aevo

El 12 de diciembre de 2025, la plataforma de derivados Aevo — anteriormente conocida como Ribbon Finance antes de su rebranding en 2023 — perdió aproximadamente 2,7 millones de dólares cuando un atacante explotó los contratos heredados de Ribbon DOV (DeFi Options Vault). La vulnerabilidad había sido introducida seis días antes por una actualización del oráculo que admitía nuevos tokens de 18 decimales pero rompía la compatibilidad con los activos heredados de 8 decimales que las bóvedas antiguas todavía usaban. Aevo cerró permanentemente las operaciones de sus bóvedas horas después de detectarse el ataque.

Qué ocurrió

Las bóvedas DOV originales de Ribbon Finance admitían varios criptoactivos como colateral para vender opciones. Las bóvedas se habían desplegado años antes del rebranding a Aevo y continuaron operando incluso después de que el foco del protocolo se trasladara al trading de perpetuos en su propia L2 Aevo.

Seis días antes del exploit, Aevo desplegó una actualización del oráculo para admitir nuevos tokens que utilizan precisión de 18 decimales. La actualización modificó la infraestructura de precios del protocolo para esperar feeds de precios de 18 decimales en todo el sistema.

La ruptura fatal de compatibilidad: algunos activos heredados en las bóvedas antiguas de Ribbon aún usan precisión de 8 decimales (un estándar común para tokens ERC-20 heredados anteriores a la convención de 18 decimales). La actualización del oráculo no incluyó escalado retrocompatible para estos activos, dejando a las bóvedas heredadas con un sistema de precios que malinterpretaba los valores de 8 decimales como si fueran de 18.

El ataque:

1. Identificó la vulnerabilidad de incompatibilidad de precisión en las bóvedas heredadas tras la actualización.
2. Desplegó un contrato inteligente malicioso para interactuar con los mercados DOV afectados.
3. Creó tres cuentas marcadas como tipo 0 (totalmente colateralizadas), cada una con colateral real mínimo.
4. Usando la incompatibilidad de precisión, los contratos creían que el colateral mínimo valía mucho más — permitiendo al atacante acuñar una gran cantidad de oTokens (tokens de trading de opciones) contra esencialmente nada.
5. El diseño de las bóvedas carecía de pagos máximos por cuenta o serie de opciones, por lo que el atacante pudo seguir acuñando y canjeando oTokens hasta que se drenaron $2,7M de los activos subyacentes de la bóveda.

Consecuencias

• Aevo cerró permanentemente todas las operaciones heredadas de las bóvedas Ribbon en cuestión de horas tras la detección.
• El equipo publicó un post-mortem y comenzó a coordinarse con socios de seguridad.
• No hubo recuperación pública desde las carteras del atacante.
• La plataforma principal de perpetuos de Aevo no se vio afectada; el cierre se limitó a la línea de productos heredada de Ribbon DOV.

Por qué importa

El incidente de Aevo / Ribbon forma parte de un patrón recurrente 2024-2026: los contratos heredados que sobreviven al mantenimiento activo de su equipo se convierten en superficie de ataque para operadores sofisticados. El patrón se repite en:

• Truebit (enero de 2026) — bonding curve de código cerrado con 5 años de antigüedad.
• Yearn iEarn (abril de 2023) — contrato yUSDT mal configurado de 3 años.
• DOVs de Aevo / Ribbon (diciembre de 2025) — bóvedas de opciones heredadas con manejo de decimales obsoleto.

Las lecciones estructurales:

1. Las actualizaciones de infraestructura compartida (oráculos, librerías) requieren pruebas de regresión de retrocompatibilidad para cada contrato dependiente, no solo para las nuevas rutas de código que la actualización está diseñada para admitir.
2. Los contratos heredados con TVL significativo deberían estar en una ruta de "deprecación gradual" — ventanas de migración explícitas, exposición máxima decreciente, pausa eventual del contrato — en lugar de dejarse operando indefinidamente sin mantenimiento activo.
3. Topes máximos de pago y rate-limits a nivel de cada contrato son una defensa crítica incluso para contratos "battle-tested", porque el modelo de amenaza incluye actualizaciones que rompen compatibilidad en otras partes del stack del protocolo, no solo bugs en el propio contrato.

La decisión de Aevo de cerrar permanentemente el producto de bóvedas en lugar de intentar repararlo y relanzarlo es cada vez más la opción racional para los equipos de protocolo: el coste de una remediación integral a menudo supera el valor de la base de usuarios restante, y un cierre limpio limita responsabilidades futuras.