Vorfall #6 Cork-Protokoll: Zwei unabhängige Schwachstellen erlauben eine verheerende Exploit-Kette

Am 28. Mai 2025 wurde das Cork Protocol auf Ethereum angegriffen [1], was zu einem Verlust von etwa 12 Millionen US-Dollar führte. Die Ursache war eine Kombination aus der Manipulation des „Historical Implied Yield Average“ (HIYA)-Preises nahe des Ablaufzeitpunkts und fehlender Zugriffskontrolle bei einem Uniswap v4 Hook-Callback. Da die HIYA-Risikoprämien exponentiell ansteigen, je näher die Restlaufzeit gegen Null geht, führten Swaps in der Spätphase zu einer künstlichen Aufblähung des HIYA. Dies hatte zur Folge, dass neu initialisierte Märkte Cover Tokens massiv unterbewerteten. Gleichzeitig fehlte bei CorkHook.beforeSwap die msg.sender-Authentifizierung, was beliebige Aufrufe mit manipulierten Parametern ermöglichte. Durch die Ausnutzung beider Schwachstellen extrahierte der Angreifer ca. 3.760e18 CT und DS und löste diese gegen wstETH ein, wodurch die Protokollreserven entleert wurden.

0x1 Hintergrund

0x1.1 Tokenomics

Das Cork Protocol [2] führt ein neues Primitiv für tokenisiertes Risiko ein, das als programmierbare Risikoschicht für On-Chain-Assets wie Vault-Token, renditetragende Stablecoins und „Liquid (Re)staking“-Token dient. Die grundlegende Komponente ist der Cork Pool, der den Mechanismus darstellt, um den herum Märkte aufgebaut werden. Jeder Cork Pool basiert auf einem Asset-Paar: Redemption Asset (RA) und Pegged Asset (PA).

Der Cork Pool nimmt Einzahlungen des Redemption Asset entgegen, welches gesperrt wird. Im Gegenzug werden zwei Token geprägt und an den Einzahler zurückgegeben: Depeg Swap (DS) und Cover Token (CT). Vor dem festgelegten Ablaufdatum können 1 DS + 1 CT/PA wieder gegen 1 RA getauscht werden; nach Ablauf kann 1 CT proportional gegen das verbleibende RA + PA im Pool eingelöst werden.

$$PA+DS=RAPA\; +\; DS\; =\; RA$$

$$CT+DS=RACT\; +\; DS\; =\; RA$$

0x1.2 Vertragsimplementierung

Sowohl DS als auch CT sind handelbar. Benutzer können CT und RA mittels NormalSwap basierend auf einer benutzerdefinierten AMM-Kurve über CorkHook handeln, während DS und RA mittels FlashSwap über Router und CorkHook gehandelt werden.

NormalSwap [Benutzerdefinierte AMM-Kurve]:

$$x^{1-t}{y}^t=kx^\{1-t\}\; y^\{t\}\; =\; k$$

FlashSwap [FlashSwapRouter.swapDsforRa]: Dieser Mechanismus ist zentral für den Exploit. Der Angreifer löst diesen Pfad später durch einen direkten, nicht authentifizierten Aufruf von beforeSwap (Abschnitt 0x2.2) aus.

1. Der Käufer transferiert RA an den Router.

2. Im ersten beforeSwap-Aufruf berechnet der Router die Menge an DS, die herausgetauscht werden soll. Falls erforderlich, leiht er RA und CT aus dem Uniswap v4 Pool, konvertiert die geliehenen CT und die DS des Protokolls in RA, behält das benötigte RA und gibt das geliehene RA an den Uniswap-Pool zurück.

3. Im zweiten beforeSwap-Aufruf zerlegt der Router RA in CT und DS via depositPsm, transferiert alle DS an den Benutzer, zahlt die geliehenen CT an den Uniswap-Pool zurück und erstattet überschüssige CT an den Käufer.

Mittelverteilung nach Ausgabe:

$$RA+CT:AMMRA+CT:\; AMM$$

$$DS:RouterDS:\; Router$$

0x1.3 Preisbildungsmechanismus für neue Ausgaben

Das Protokoll verwendet HIYA (Historical Implied Yield Average), berechnet als die kumulative Summe aus Volumen ($v_{T}v\_T$) × Risikoprämie ($r_{T}r\_T$), die dazu dient, Risikoprämien zu messen und Initialisierungspreise bei Ablauf anzupassen. Wenn HIYA hoch ist, nimmt das Protokoll ein höheres Depeg-Risiko an, was zu einer niedrigeren anfänglichen CT-Preisgestaltung führt.

$KumulativerHIYA={\sum }_T{r}_T{v}_{T}Kumulativer\backslash \; HIYA\; =\; \backslash sum\_T\; r\_T\; v\_T$

Die Berechnung der Risikoprämie ($r_{T}r\_T$) besteht aus zwei Komponenten: hohe CT-Preise korrelieren mit niedrigen Werten für $r_{T}r\_T$ (was intuitiv ist), und die Ablaufzeit $TT$ hat einen exponentiellen Verstärkungseffekt. Kurz vor Ablauf nähert sich $TT$ Null, wodurch der Exponent $1\mathrm{/}T1/T$ schnell ansteigt. Dies verstärkt selbst geringe Veränderungen des CT-Preises zu großen Risikoprämienwerten.

$$r_T=(F\mathrm{/}{p}_T{)}^{1\mathrm{/}T}-1r\_T\; =\; (F\; /\; p\_T)^\{1/T\}\; -\; 1$$

• $FF$ ist 1

• $P_{T}P\_T$ ist der Preis von CT

• $TT$ ist die Restlaufzeit, normalisiert zwischen 1 und 0

Zur Veranschaulichung der Verstärkung: Wenn CT zu $p_T=0.95p\_T\; =\; 0.95$ gehandelt wird (ein Rabatt von 5 %), beträgt die Risikoprämie bei $T=0.5T\; =\; 0.5$ (die Hälfte bis zum Ablauf):

$$r_{0.5}=(1\mathrm{/}0.95{)}^{1\mathrm{/}0.5}-1=(1.053{)}^2-1\approx 0.108r\_\{0.5\}\; =\; (1/0.95)^\{1/0.5\}\; -\; 1\; =\; (1.053)^\{2\}\; -\; 1\; \backslash approx\; 0.108$$

Bei $T=0.01T\; =\; 0.01$ (nahe Ablauf) erzeugt der gleiche CT-Preis:

$$r_{0.01}=(1\mathrm{/}0.95{)}^{1\mathrm{/}0.01}-1=(1.053{)}^{100}-1\approx 167r\_\{0.01\}\; =\; (1/0.95)^\{1/0.01\}\; -\; 1\; =\; (1.053)^\{100\}\; -\; 1\; \backslash approx\; 167$$

Der gleiche CT-Rabatt von 5 % erzeugt eine ~1.500-mal größere Risikoprämie nahe dem Ablauf. Diese exponentielle Sensitivität ist der Manipulationsvektor: Ein Swap, der kurz vor Ablauf ausgeführt wird, lässt HIYA unangemessen in die Höhe schnellen und verzerrt den Initialisierungspreis des nächsten Marktes.

0x2 Schwachstellenanalyse

Der betroffene Markt umfasst folgende Token:

Der Klarheit halber bezieht sich dieser Bericht im Folgenden auf die Token anhand ihrer abstrakten Rollen (RA, DS, CT) und nicht anhand ihrer konkreten Namen, es sei denn, die Unterscheidung ist wichtig.

Der Angreifer extrahierte sowohl DS als auch CT aus dem AMM und dem Router mittels zwei verschiedener Methoden. Da DS + CT gegen RA eingelöst werden können, ermöglicht der Erhalt beider eine direkte Gewinnextraktion. Der Angriff besteht aus zwei Komponenten.

0x2.1 Extraktion von Cover Token: HIYA-Manipulation führt zu künstlich niedrigen Initialisierungspreisen

Wenn eine Marktperiode abläuft, initialisiert das Protokoll die nächste Periode unter Verwendung des accumulatedHIYA aus der vorangegangenen Periode, um das CT/RA-Preisverhältnis im AMM festzulegen. Ein höheres HIYA signalisiert ein höher wahrgenommenes Depeg-Risiko, was in einen niedrigeren anfänglichen CT-Preis übersetzt wird.

Da HIYA bei jedem Swap aktualisiert wird und Risikoprämien einbezieht (Abschnitt 0x1.3), und da Risikoprämien exponentiell wachsen, wenn $T\to 0T\; \backslash to\; 0$, blähen Swaps, die kurz vor Ablauf ausgeführt werden, das accumulatedHIYA um Größenordnungen auf. Der Angreifer nutzte dies aus, indem er SwapRaForDs() kurz vor Ablauf aufrief, wodurch eine große Risikoprämie generiert wurde, die in das HIYA einfloss.

Als die neue Marktperiode anschließend initialisiert wurde, las das Protokoll das aufgeblähte HIYA, interpretierte es als extremes Depeg-Risiko und setzte den anfänglichen AMM-Preis für CT weit unter dessen fairen Wert. Der Angreifer tauschte daraufhin RA gegen CT zu diesem verzerrten Preis und erwarb günstig eine große Position an CT.

0x2.2 Extraktion von Depeg Swap: Fehlende Zugriffskontrolle in CorkHook.beforeSwap

Im Standarddesign von Uniswap v4 Hooks wird beforeSwap exklusiv vom PoolManager während eines Swaps aufgerufen. Die Implementierung von Cork setzte diese Einschränkung nicht durch:

// Fehlend: require(msg.sender == address(poolManager));
function beforeSwap(
    address sender,
    PoolKey calldata key,
    IPoolManager.SwapParams calldata params,
    bytes calldata hookData
) external override returns (bytes4, BeforeSwapDelta, uint24) {
    ...
}

Ohne diese Prüfung kann jeder externe Vertrag beforeSwap direkt mit beliebigen hookData aufrufen. Wenn hookData nicht leer ist, tritt die Funktion in den FlashSwap-Ausführungspfad (Abschnitt 0x1.2) ein, der RA via depositPsm in CT und DS zerlegt. Der Angreifer nutzte dies aus, indem er beforeSwap direkt mit manipulierten hookData aufrief, die die Token eines gefälschten Marktes spezifizierten, was das Protokoll dazu veranlasste, Token zu zerlegen und die Ergebnisse an den Angreifer zu übertragen.

0x2.3 Wie die beiden Schwachstellen zusammenwirken

Keine der beiden Schwachstellen allein reicht aus, um die vollen 12 Millionen US-Dollar zu extrahieren.

Die HIYA-Manipulation verschafft dem Angreifer günstiges CT, aber CT allein kann nicht gegen RA eingelöst werden. Die Einlösungsformel erfordert beide Token: CT + DS = RA. Der Angreifer benötigt also weiterhin eine Möglichkeit, DS zu erhalten.

Die fehlende Zugriffskontrolle in beforeSwap bietet diesen Weg. Durch den direkten Aufruf von beforeSwap mit manipulierten hookData kann der Angreifer den FlashSwap-Zerlegungspfad mit beliebigen Parametern auslösen. Um echtes DS über diesen Pfad zu erhalten, setzt der Angreifer einen gefälschten Markt auf, der echtes DS als sein RA deklariert, und ruft dann beforeSwap auf, um dieses „RA“ (echtes DS) in gefälschtes CT und gefälschtes DS zu zerlegen, welche über den gefälschten Markt wieder gegen echtes DS getauscht werden können.

Mit sowohl CT (aus der HIYA-Manipulation) als auch DS (aus dem nicht authentifizierten beforeSwap-Aufruf über den gefälschten Markt) in der Hand, löst der Angreifer diese 1:1 gegen RA (wstETH) ein.

0x3 Angriffsanalyse

Der Angriff entfaltet sich über drei Transaktionen, wobei jede einer Phase entspricht: Aufblähen des HIYA, Erwerb von günstigem CT und Extraktion von DS zur Vervollständigung des Einlösungspaars.

0x3.1 Vorbereitung: Aufblähen des HIYA

In dieser Transaktion rief der Angreifer SwapRaForDs() kurz vor Ablauf der Marktperiode auf. Da $TT$ nahe Null war, generierte dieser Swap eine überproportional große Risikoprämie (Abschnitt 0x1.3) und blähte accumulatedHIYA auf.

Der Angreifer hält nach dieser Phase: DS aus dem Swap (wird später in Phase 0x3.3 verwendet) und ein aufgeblähtes, On-Chain gespeichertes accumulatedHIYA.

0x3.2 Initialisierung: Erwerb von günstigem CT

In dieser Transaktion wurde die neue Marktperiode initialisiert. Das Protokoll las das aufgeblähte accumulatedHIYA und setzte ein verzerrtes CT/RA-Preisverhältnis im AMM, wodurch der Preis für CT weit unter seinen fairen Wert gedrückt wurde. Der Angreifer tauschte daraufhin ca. 0,000003e18 RA gegen 3.760e18 CT zu diesem deflationierten Preis.

Der Angreifer hält nach dieser Phase: eine große CT-Position (günstig erworben durch den manipulierten Initialisierungspreis).

0x3.3 Extraktion: Erhalt von DS über den gefälschten Markt

Diese Phase nutzt die Schwachstelle in der Zugriffskontrolle (Abschnitt 0x2.2), um DS zu extrahieren und damit das für die RA-Einlösung notwendige CT + DS-Paar zu vervollständigen. Die Kerntechnik ist ein gefälschter Markt, der das echte DS als sein Redemption Asset behandelt:

Die entscheidenden Schritte der Angriffstransaktion:

1. Der Angreifer tauschte zuerst RA gegen DS auf dem legitimen Markt.

   Der Angreifer hält: echtes DS.

2. Der Angreifer implementierte und initialisierte den gefälschten Markt und legte echtes DS als gefälschtes RA fest.

   

3. Der Angreifer rief beforeSwap direkt auf (unter Ausnutzung der fehlenden Zugriffskontrolle) mit nicht leeren hookData, was den FlashSwap-Ausführungspfad gegen den gefälschten Markt auslöste. Innerhalb der hookData spezifizierte der Angreifer paymentToken als gefälschtes CT, was das Protokoll dazu veranlasste, die RA-Zerlegungslogik gegen den gefälschten Markt auszuführen.

   

4. Das Protokoll zerlegte das gesamte gefälschte RA (d. h. echtes DS) in gefälschtes CT und gefälschtes DS. Der gesamte Anteil an gefälschtem DS wurde an den Angreifer übertragen, und der Anteil an gefälschtem CT (abzüglich eines minimalen paymentAmount) wurde erstattet.

   Der Angreifer hält: 3.761e18 gefälschtes CT + 3.761e18 gefälschtes DS (beides abgeleitet aus echtem DS).

5. Der Angreifer tauschte gefälschtes CT und gefälschtes DS zurück in gefälschtes RA innerhalb des gefälschten Marktes und gewann so echtes DS zurück.

   Der Angreifer hält: 3.761e18 echtes DS (zurückgewonnen).

6. Der Angreifer kombinierte das zurückgewonnene DS mit dem in Abschnitt 0x3.2 erhaltenen CT, um RA (wstETH) einzulösen und so die Gewinnextraktion abzuschließen.

   Der Angreifer hält: 3.760e18 RA (wstETH) Gewinn (d. h. 12 Mio. USD).

Zusammenfassung

Dieser Vorfall kombinierte zwei unabhängige Schwachstellen, von denen keine für sich allein ausgereicht hätte, zu einer einzigen Exploit-Kette, die dem Protokoll 12 Millionen US-Dollar entzog.

• Exponentielle Risikoprämie nahe Ablauf: Die HIYA-Preisformel verstärkt Risikoprämien, wenn die Restlaufzeit gegen Null geht, was Swaps in der Spätphase zu einem Manipulationsvektor für Markt-Reinitialisierungspreise macht.
• Fehlende Absenderprüfung bei Hook-Callbacks: CorkHook.beforeSwap erzwang nicht, dass msg.sender der PoolManager ist, was direkte Aufrufe mit beliebigen Parametern ermöglichte und es dem Angreifer erlaubte, den FlashSwap-Ausführungspfad zu fälschen.
• Interaktion zwischen Modulen als blinder Fleck: Das ökonomische Design (HIYA-basierte Preisgestaltung) und die Lücke in der Zugriffskontrolle (nicht authentifizierter Hook-Callback) lagen in separaten Modulen. Ihre Interaktion schuf einen ausnutzbaren Pfad, den eine Analyse einzelner Module wahrscheinlich nicht erkannt hätte.

Referenz

1. https://www.cork.tech/blog/post-mortem

2. https://docs.cork.tech/core-concepts/cork-pool

Über BlockSec

BlockSec ist ein Full-Stack Blockchain-Sicherheits- und Krypto-Compliance-Anbieter. Wir entwickeln Produkte und Dienstleistungen, die Kunden dabei helfen, Code-Audits durchzuführen (einschließlich Smart Contracts, Blockchain und Wallets), Angriffe in Echtzeit abzufangen, Vorfälle zu analysieren, illegale Gelder zurückzuverfolgen und AML/CFT-Verpflichtungen über den gesamten Lebenszyklus von Protokollen und Plattformen hinweg zu erfüllen.

BlockSec hat zahlreiche Papiere zur Blockchain-Sicherheit auf renommierten Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe auf DeFi-Anwendungen gemeldet, zahlreiche Hacks blockiert, um mehr als 20 Millionen Dollar zu retten, und Milliarden an Kryptowährungen gesichert.

• Offizielle Website: https://blocksec.com/

• Offizieller Twitter-Account: https://twitter.com/BlockSecTeam

• 🔗 BlockSec Auditing Service : Anfrage einreichen

• 🔗 Phalcon Security APP: Demo buchen

• 🔗 Phalcon Compliance