Buchhaltungs-Exploit im Liquiditätspool von NemTokenV2

Am 22. Oktober 2026 wurde der NemTokenV2-Vertrag — ein auf PancakeSwap gehandelter Token der BNB Chain, der nichts mit der nativen NEM/XEM-Blockchain zu tun hat — um rund 822.000 US-Dollar ausgebeutet. Der Verlust ging auf einen Logikfehler im Code des Tokens selbst zurück, nicht auf einen gestohlenen Schlüssel oder eine externe Abhängigkeit. Die Sicherheitsfirmen SlowMist und CertiK meldeten den Vorfall noch am selben Tag; SlowMist bezifferte den Schaden auf etwa 821.920 US-Dollar.

Was geschah

NemTokenV2 hatte einen eigenen „Sell-Recycle"-Buchhaltungsmechanismus in seine Transferlogik eingebettet. Der Vertrag behandelte jeden Transfer von Token in sein PancakeSwap-Liquiditätspaar als Verkaufsvolumen, ohne zu prüfen, ob ein Tausch tatsächlich abgewickelt worden war. Da der reale Token-Bestand des Paars seine verbuchten Reserven übersteigen konnte, war dieser Überschuss abschöpfbar.

Der Angreifer nutzte die Lücke in einer engen Schleife aus: Er schickte NEM in den USDT/NEM-Pool, rief skim() auf, um den Überschuss zu räumen, und löste die vertragseigene Routine flushLpSellRecycle() aus. Laut SlowMist wurde die Sequenz rund 42-mal wiederholt, wodurch die NEM-Reserven des Pools stetig schrumpften und der Token-Preis stieg. Anschließend verkaufte der Angreifer die verbliebenen NEM zum verzerrten Preis gegen USDT und überbrückte die Erlöse nach Ethereum.

Nachwirkungen

Zum Zeitpunkt der ersten Veröffentlichungen hatte das NemTokenV2-Team keine offizielle Erklärung abgegeben, keinen Fix genannt und keine Wiederbeschaffung gemeldet. SlowMist erklärte, die Adressen von Angreifer, Exploit-Vertrag und Token veröffentlicht zu haben, doch die öffentliche Berichterstattung gab sie nicht wieder, und es wurden weder bestätigte Transaktions-Hashes noch eine Identität des Angreifers festgestellt.

Warum es wichtig ist

Der NemTokenV2-Verlust erinnert daran, dass die Transfer-Hooks eines Tokens selbst Angriffsfläche sind. Maßgeschneiderte „Tax"-, „Reflection"- oder „Recycle"-Logik, die bei jedem Transfer die Buchhaltung des Liquiditätspools verändert, lädt genau diese Fehlerklasse ein: Vertraut ein Vertrag seiner internen Buchführung mehr als dem abgewickelten Zustand des AMM, kann ein Angreifer künstliches Verkaufsvolumen erzeugen und die Differenz abschöpfen. Es ist dieselbe Reserve- und Preisverzerrung wie bei Papertrade und Tectonic und unterstreicht, warum selbstbuchende Token-Verträge gegen die realen Bestände des Paars abgleichen sollten — niemals umgekehrt.