Cork Protocol Depeg-Swap-Hook

Am 28. Mai 2025 um 11:39 UTC wurde das von a16z unterstützte Depeg-Versicherungsprotokoll Cork Protocol um 3.761 wstETH entleert — etwa 12 Millionen US-Dollar zur Zeit — durch einen ausgeklügelten Exploit, der Corks Markt-Erzeugungs-Logik kombiniert mit einem bösartigen Uniswap-v4-Hook missbrauchte. Der Drain wurde in 16 Minuten ausgeführt.

Was geschah

Cork Protocol erlaubte Nutzern, sich gegen Asset-Depeg-Risiko abzusichern. Der Mechanismus:

• PA (Pegged Asset) — was Nutzer schützen wollten (z. B. wstETH).
• RA (Reserve Asset) — woran der PA gepeggt sein sollte.
• DS (Depeg Swap) — ein Token, den Nutzer kauften, um sich gegen PA-Depegging zu versichern.
• CS (Covered Swap) — ein Token, den Nutzer verkauften, um gegen Depegging zu wetten.

Corks Markt-Erzeugungsfunktion erlaubte jedem Nutzer, permissionless neue Märkte zu erstellen, indem er den PA und RA spezifizierte. Der fatale Fehler: Die Funktion validierte nicht, dass der RA ein legitimer zugrundeliegender Asset war — speziell prüfte sie nicht, dass ein RA nicht selbst die DS eines anderen bestehenden Marktes war.

Der Angriff:

1. Erstellte einen neuen Markt mit dem vom Angreifer gewählten PA und einem RA, der auf die DS eines bestehenden legitimen Marktes verwies.
2. Deployte einen bösartigen Uniswap-v4-Hook, der so designt war, dass er Autorisierungs-Prüfungen in Corks CorkHook- und FlashSwapRouter-Verträgen umging.
3. Nutzte Corks Rollover-Preislogik kurz vor Ablauf des legitimen Marktes aus — manipulierte einen Input, der beeinflusste, wie das Protokoll die Depeg/Cover-Positionen während des Rollovers bewertete.
4. Der bösartige Hook umging die Autorisierungs-Prüfungen in Corks Swap-Pfad, was dem Angreifer erlaubte, das zugrundeliegende wstETH abzuheben, das den ursprünglichen Markt absicherte.
5. Entzog 3.761 wstETH und konvertierte es innerhalb von 16 Minuten in ETH.

Folgen

• Cork pausierte alle Marktoperationen und veröffentlichte ein detailliertes Post-Mortem.
• Das Team koordinierte mit White-Hat-Ermittlern bei der Verfolgung; teilweise Rückgewinnung über Cross-Exchange-Kooperation folgte, gab aber nicht den Großteil der Mittel zurück.
• Der Exploit wurde zu einer bemerkenswerten Fallstudie über Uniswap-v4-Hook-Risiken, da der bösartige Hook zentral für die Umgehung von Corks Autorisierungs-Logik war.

Warum es wichtig ist

Cork Protocol ist einer der ersten großen Vorfälle der Post-Uniswap-v4-Ära, in dem der Hooks-Mechanismus — ein bewusst mächtiges Primitiv, das externen Verträgen erlaubt, Pool-Operationen abzufangen — eine tragende Komponente eines Exploits wurde. Hooks erlauben Protokollen, elegant zu komponieren, aber sie erlauben auch Angreifern, bösartig zu komponieren auf Arten, die Protokolle, die ihre eigene Access-Control implementieren, nicht antizipieren.

Die strukturelle Lektion, gut dokumentiert, aber neu relevant für v4:

1. Permissionless Markt-Erzeugung erfordert strikte Validierung jedes Inputs — einschließlich transitiver Prüfungen gegen den State anderer Märkte, auf die der neue Markt verweisen könnte.
2. Hook-Integrationen müssen standardmäßig als nicht vertrauenswürdige Aufrufer behandelt werden, unabhängig davon, wie das integrierende Protokoll konfiguriert ist.
3. Selbst gut auditierte Protokolle können neuartige Schwachstellen ausliefern, wenn sie an der Schnittstelle mehrerer primitiver Komposabilitätsschichten sitzen. Corks Audit hatte jede Komponente isoliert geprüft; der Exploit kombinierte sie.

Der Cork-Vorfall ist auch bemerkenswert wegen der Geschwindigkeit des Drains (16 Minuten) und der Präzision des Angriffs (Ausführung kurz vor Ablauf des legitimen Marktes). Diese deuten auf einen Angreifer mit tiefer Vertrautheit mit dem Protokoll hin — möglicherweise aus früherer Forschung oder Insider-Wissen über den Codebase.