mySwap-Exploit der Pool-Buchführung per Fake-Token

Am 19. Juni 2026 wurde mySwap — ein Concentrated-Liquidity-AMM auf Starknet — um etwa 305.000 US-Dollar erleichtert, nachdem ein Angreifer die Buchführungslogik der Pools mit einem wertlosen Token missbraucht hatte. Der Abzug begann gegen 07:15 UTC und leerte die im gemeinsamen Vault des Protokolls verbliebene Liquidität nahezu vollständig.

Was geschah

Der Angreifer brachte einen gefälschten Token namens EVIL in Umlauf und nutzte ihn, um den Buchführungspfad zu verfälschen, der die Concentrated-Liquidity-Pools (CL) von mySwap mit ihrem gemeinsamen Vault verbindet. Da die Buchhaltung des Vaults den über einen angreifergesteuerten Token gemeldeten Beständen vertraute, konnte der Angreifer über eine erlaubnisfreie Interaktion seinen Anspruch aufblähen und echte Vermögenswerte abziehen, die andere Liquiditätsanbieter eingebracht hatten. On-Chain-Tracker bezifferten die Beute auf etwa 137,96 ETH, 45.000 USDC, 19.900 USDT und 230.000 STRK. Entscheidend ist: Die Oberfläche von mySwap war seit über sechs Monaten für neue Liquiditätseinzahlungen geschlossen, sodass es sich bei den abgezogenen Beständen überwiegend um Rest-LP-Positionen über mehr als 100.000 alte Positionen handelte — eine ruhende Angriffsfläche, die niemand aktiv beobachtete. Anschließend brückte der Angreifer die Erlöse von Starknet weg und leitete sie über Railgun, um die On-Chain-Spur zu verwischen.

Folgen

Der Exploit entzog den betroffenen Pools fast die gesamte verbliebene Liquidität. Da die Mittel rasch über Railgun gewaschen wurden, war zum Zeitpunkt der Erstellung keine Rückholung gemeldet — weder eine White-Hat-Rückgabe noch ein ausgehandelter Vergleich. Der Vorfall verdeutlicht, wie ein faktisch abgewickeltes Protokoll — dessen Verträge aber weiterhin aktiv sind und Rest-Nutzermittel halten — noch lange ein stehendes Ziel bleibt, nachdem sein Team weitergezogen ist.

Warum es wichtig ist

mySwap erinnert daran, dass ruhende DeFi-Verträge keine toten Verträge sind: Solange ein Vault Wert hält und erlaubnisfreie Interaktionen zulässt, ist seine Buchführung eine Angriffsfläche, selbst wenn das Frontend dunkel ist. Der Fake-Token-Vektor ähnelt BnbLabubu, wo ein manipulierter Token-Parameter pool-leerende Mathematik auf einem PancakeSwap-Paar auslöste, und er reiht sich neben zkLend als weiteres Starknet-Protokoll ein, das durch ausnutzbare interne Buchführung statt durch ein gebrochenes kryptografisches Primitiv zu Fall kam. Für AMMs gilt: Der sicherste Rest-Pool ist einer, dessen Verträge vollständig geleert oder eingefroren wurden — übrig gebliebene Liquidität in einem veralteten Vault ist Haftungsrisiko, kein Erbe.