Aevo Legacy Ribbon DOV Oracle-Drain

Am 12. Dezember 2025 verlor die Derivate-Plattform Aevo — vor dem Rebranding 2023 als Ribbon Finance bekannt — etwa 2,7 Millionen US-Dollar, als ein Angreifer die alten Ribbon-DOV-Verträge (DeFi Options Vault) ausnutzte. Die Schwachstelle war sechs Tage zuvor durch ein Oracle-Upgrade eingeführt worden, das neue 18-Dezimal-Tokens unterstützte, aber die Kompatibilität mit den alten 8-Dezimal-Assets, die die alten Vaults noch nutzten, brach. Aevo stellte den Vault-Betrieb dauerhaft ein, Stunden nachdem der Angriff entdeckt wurde.

Was geschah

Die ursprünglichen DOV-Vaults von Ribbon Finance unterstützten verschiedene Krypto-Assets als Sicherheit für den Verkauf von Optionen. Die Vaults waren Jahre vor dem Aevo-Rebranding deployt worden und liefen weiter, auch nachdem sich der Fokus des Protokolls auf den Perpetuals-Handel auf seinem eigenen Aevo L2 verlagert hatte.

Sechs Tage vor dem Exploit deployte Aevo ein Oracle-Upgrade, um neue Tokens mit 18-Dezimal-Präzision zu unterstützen. Das Upgrade modifizierte die Preisinfrastruktur des Protokolls so, dass durchgehend 18-Dezimal-Preisfeeds erwartet wurden.

Der fatale Kompatibilitätsbruch: Einige Legacy-Assets in den älteren Ribbon-Vaults nutzen noch immer 8-Dezimal-Präzision (ein gängiger Standard für ältere ERC-20-Tokens, die vor der 18-Dezimal-Konvention liegen). Das Oracle-Upgrade enthielt keine rückwärtskompatible Skalierung für diese Assets und ließ die Legacy-Vaults mit einem Preissystem zurück, das die 8-Dezimal-Werte fälschlich als 18-Dezimal interpretierte.

Der Angriff:

1. Identifizierte die Präzisions-Diskrepanz-Schwachstelle in den Legacy-Vaults nach dem Upgrade.
2. Deployte einen bösartigen Smart Contract, um mit den betroffenen DOV-Märkten zu interagieren.
3. Erstellte drei Konten, die als Typ 0 markiert waren (vollständig besichert), jeweils mit minimaler tatsächlicher Sicherheit.
4. Durch die Präzisions-Diskrepanz glaubten die Verträge, die minimale Sicherheit sei weit mehr wert — was es dem Angreifer erlaubte, eine große Anzahl von oTokens (Options-Handelstokens) gegen praktisch nichts zu prägen.
5. Im Design der Vaults fehlten maximale Auszahlungen pro Konto oder Optionsserie, sodass der Angreifer oTokens immer wieder prägen und einlösen konnte, bis 2,7 Mio. USD aus den zugrundeliegenden Vault-Assets entzogen waren.

Folgen

• Aevo stellte alle alten Ribbon-Vault-Operationen dauerhaft ein, innerhalb von Stunden nach Erkennung.
• Das Team veröffentlichte ein Post-Mortem und begann die Koordination mit Sicherheitspartnern.
• Keine öffentliche Rückerstattung aus den Wallets des Angreifers.
• Aevos Haupt-Perpetuals-Plattform war nicht betroffen; die Abwicklung beschränkte sich auf die Legacy-Ribbon-DOV-Produktlinie.

Warum es wichtig ist

Der Aevo/Ribbon-Vorfall ist Teil eines wiederkehrenden Musters 2024-2026: Legacy-Verträge, die die aktive Wartung ihres Teams überdauern, werden zur Angriffsfläche für versierte Akteure. Das Muster wiederholt sich bei:

• Truebit (Jan 2026) — 5 Jahre alte Closed-Source-Bonding-Curve.
• Yearn iEarn (Apr 2023) — 3 Jahre alter fehlkonfigurierter yUSDT-Vertrag.
• Aevo/Ribbon DOVs (Dez 2025) — Legacy-Options-Vaults mit veralteter Dezimalbehandlung.

Die strukturellen Lektionen:

1. Upgrades an gemeinsamer Infrastruktur (Oracles, Bibliotheken) erfordern Rückwärtskompatibilitäts-Regressionstests für jeden abhängigen Vertrag, nicht nur für die neuen Codepfade, die das Upgrade unterstützen soll.
2. Legacy-Verträge mit signifikantem TVL sollten auf einem „graceful deprecate"-Pfad sein — explizite Migrationsfenster, sinkende Maximalexposition, schließlich Vertrags-Pause — statt unbegrenzt ohne aktive Wartung weiterzulaufen.
3. Maximalauszahlungs-Caps und Rate-Limits auf Vertragsebene sind eine kritische Verteidigung selbst für „kampferprobte" Verträge, weil das Bedrohungsmodell kompatibilitätsbrechende Upgrades anderswo im Stack einschließt, nicht nur Bugs im Vertrag selbst.

Aevos Entscheidung, das Vault-Produkt dauerhaft einzustellen, statt Reparatur und Relaunch zu versuchen, ist zunehmend die rationale Wahl für Protokoll-Teams: Die Kosten umfassender Nachbesserung übersteigen oft den Wert der verbleibenden Nutzerbasis, und ein sauberer Shutdown begrenzt zukünftige Haftung.