4,72 Mio. $ verloren: TAC, Transit Finance & mehr | BlockSec Weekly

In der vergangenen Woche (11.05.2026 - 17.05.2026) identifizierte BlockSec mehrere Angrifssvorfälle in verschiedenen Blockchain-Ökosystemen. Die folgende Tabelle listet 3 bemerkenswerte Vorfälle mit geschätzten Gesamtverlusten von etwa 4,72 Mio. USD auf.

Drei Vorfälle wurden für eine eingehende Analyse ausgewählt:

• Transit Finance: Ein veralteter Swap-Bridge-Vertrag, der Berichten zufolge seit 2022 als obsolet galt, wurde durch die Weiterleitung von beliebigem Calldata ausgenutzt, um Nutzer zu bestehlen, die ihre USDT-Freigaben nie widerrufen hatten.
• TAC: Der größte Verlust in dieser Woche (~2,8 Mio. USD), bei dem eine fehlende kanonische Wallet-Verifizierung im Jetton-Einzahlungsprozess auf der TON-Seite es ermöglichte, dass gefälschte Einzahlungsbenachrichtigungen Cross-Chain-Minting auf TAC EVM auslösten.
• Boost Hook: Ein auf Uniswap V4 Hooks basierendes Perpetual-Protokoll, das durch Spotpreis-Manipulation ausgenutzt wurde, was die Risiken der Verwendung von slot0-Preisen als Einstiegspreise für gehebelte Positionen verdeutlicht.

Wöchentliches Highlight: Transit Finance

Dieser Vorfall wird hervorgehoben, da er ein anhaltendes Risikomuster verdeutlicht: veraltete Smart Contracts mit noch bestehenden Token-Freigaben. Selbst wenn ein Protokoll einen Vertrag als obsolet betrachtet, bleiben Nutzer, die ihre Freigaben nie widerrufen haben, unbegrenzt gefährdet, was veraltete Infrastrukturen zu einer latenten Angriffsfläche macht.

Am 12. Mai 2026 wurde Transit Finance, ein Cross-Chain-Swap- und Bridge-Aggregationsprotokoll, auf TRON für etwa 1,88 Mio. USD ausgenutzt [1]. Der Angreifer missbrauchte einen Ausführungspfad für beliebigen Calldata im veralteten TransitMixSwapBridge-Vertrag, um USDT.transferFrom() bei Nutzern aufzurufen, die zuvor unbegrenzte USDT-Freigaben für den Freigabevertrag von Transit erteilt hatten. Obwohl der betroffene Vertrag Berichten zufolge seit 2022 nicht mehr verwendet wurde, blieben die Freigabebeziehungen aktiv und ausnutzbar.

Hintergrund

Transit Finance ist ein Cross-Chain-Swap- und Bridge-Aggregationsprotokoll, das es Nutzern ermöglicht, Vermögenswerte über mehrere Blockchains hinweg, einschließlich TRON, zu tauschen und zu übertragen. Die TRON-Implementierung des Protokolls enthielt historisch einen TransitMixSwapBridge-Vertrag, der Swap- und Bridge-Ausführungen durch einen internen Proxy und eine Freigabe-Pipeline leitete.

Schwachstellenanalyse

Der fehlerhafte TransitMixSwapBridge-Vertrag (TUfPjK...Ukbc4) enthielt eine Funktionalität zur Weiterleitung von beliebigem Calldata: vom Angreifer kontrollierter Calldata konnte ohne ausreichende Validierung durch die interne Ausführungskette von Transit geleitet werden. Dies ermöglichte es dem Angreifer, Payloads zu erstellen, die letztendlich USDT.transferFrom()-Aufrufe durch den Freigabevertrag von Transit (TransitApproveGovernanceTron) auslösten, der weiterhin unbegrenzte, von Nutzern erteilte Freigaben hielt.

Der Kernfehler besteht darin, dass der Ausführungspfad keinerlei Einschränkungen hinsichtlich des Ziels oder des Calldatas des weitergeleiteten Aufrufs vornahm, was die Ausführung beliebiger externer Aufrufe unter der Autorität des Freigabevertrags ermöglichte.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 3a981b83...ce918ac2.

• Schritt 1: Der Angreifer rief den TransitMixSwapBridge-Vertrag mit manipuliertem Calldata auf. Der Calldata wurde durch den Proxy und die Bridge-Ausführungs-Pipeline von Transit an den Freigabevertrag weitergeleitet.

• Schritt 2: Der Freigabevertrag von Transit (TransitApproveGovernanceTron) führte vom Angreifer kontrollierte USDT.transferFrom()-Aufrufe aus. Da Nutzer diesem Vertrag zuvor unbegrenzte USDT-Freigaben erteilt hatten, waren die Aufrufe erfolgreich.

• Schritt 3: USDT wurde direkt von den Wallets der Opfer an die vom Angreifer kontrollierte Adresse übertragen, insgesamt etwa 1,88 Mio. USD.

Fazit

Der Vorfall wurde durch eine Schwachstelle bei der Ausführung von beliebigem Calldata in einem veralteten TransitMixSwapBridge-Vertrag in Kombination mit persistenten unbegrenzten Token-Freigaben verursacht. Obwohl der Vertrag Berichten zufolge seit 2022 nicht mehr verwendet wurde, blieben die Freigabebeziehungen aktiv und ausnutzbar. Die wichtigsten Lehren sind: (1) veraltete Verträge sollten vollständig außer Betrieb genommen werden, einschließlich des Widerrufs jeglicher Freigabeberechtigungen, (2) Pfade zur Weiterleitung von beliebigem Calldata müssen sowohl die Zieladresse als auch den Funktionsselektor validieren, und (3) Nutzer sollten unnötige Token-Freigaben regelmäßig überprüfen und widerrufen, insbesondere bei veralteten Protokollen.

Referenzen

• [1] BlockSec Phalcon Alert

Weitere Vorfälle dieser Woche

TAC

Am 12. Mai 2026 wurde TAC, ein Bridge-Protokoll, das TON mit EVM-kompatibler Ausführung erweitert, für etwa 2,8 Mio. USD ausgenutzt [1]. Die Ursache war eine fehlende kanonische Wallet-Verifizierung im Jetton-Einzahlungsprozess auf der TON-Seite: Der TAC JettonProxy akzeptierte eine JettonNotify von einer nicht-kanonischen Jetton-Wallet, ohne zu verifizieren, ob der Absender mit der vom offiziellen Jetton-Master abgeleiteten kanonischen Wallet übereinstimmte. Dies ermöglichte es dem Angreifer, gefälschte Einzahlungsbenachrichtigungen zu übermitteln, die gültige Cross-Chain-Nachrichten auslösten und zugeordnete Vermögenswerte auf TAC EVM prägten.

Hintergrund

TON ist nativ nicht EVM-kompatibel, was den direkten Zugriff auf DeFi-Anwendungen im Ethereum-Stil einschränkt. TAC erweitert TON durch eine Bridge, die es ermöglicht, auf TON stammende Vermögenswerte und Nachrichten in einer EVM-kompatiblen Umgebung zu verarbeiten. Bei diesem Design werden Token-Einzahlungen auf der TON-Seite in Cross-Chain-Nachrichten umgewandelt und als zugeordnete Vermögenswerte auf TAC EVM geprägt.

Schwachstellenanalyse

Der fehlerhafte TAC JettonProxy-Vertrag ist unter EQAChA...xMdw bereitgestellt.

Die Schwachstelle ist das Fehlen einer kanonischen Wallet-Verifizierung im Token-Eingangspfad auf der TON-Seite. TAC JettonProxy akzeptierte JettonNotify-Nachrichten, ohne zu überprüfen, ob msg.sender die kanonische Jetton-Wallet war, die vom offiziellen Jetton-Master für den beanspruchten Eigentümer abgeleitet wurde. Aufgrund dessen konnte eine nicht-kanonische Wallet eine gefälschte JettonNotify senden, die als rechtmäßige Einzahlung behandelt wurde und eine gültige TVM-zu-EVM Cross-Chain-Nachricht auslöste.

Angriffsanalyse

Die folgende Analyse basiert auf den Transaktionen 549807fd...3757e1 und 0x0942a5...0dad224d.

• Schritt 1: Der Angreifer stellte einen Wallet-ähnlichen Vertrag bereit und nutzte ihn, um eine JettonNotify an TAC JettonProxy zu senden. Das Payload beanspruchte einen Token-Transfer und enthielt ein forward_payload mit Cross-Chain-Ausführungsdaten.

• Schritt 2: TAC JettonProxy akzeptierte die Benachrichtigung und sendete eine nachgelagerte Cross-Chain-Nachricht an TAC CCL. Die Absender-Wallet war nicht die vom offiziellen USD₮ (USDT auf TON)-Master für den jeweiligen Eigentümer abgeleitete kanonische Wallet, dennoch wurde die Benachrichtigung als gültiger Einzahlungsprozess verarbeitet.

• Schritt 3: TAC EVM verarbeitete die Bridge-Nachricht und prägte zugeordnete Vermögenswerte, darunter etwa 2,17 Mio. zugeordneter USD₮, womit der Exploit-Pfad abgeschlossen war.

Fazit

Der Vorfall wurde durch eine fehlende kanonische Wallet-Verifizierung im Jetton-Einzahlungsprozess von TAC auf der TON-Seite verursacht. Eine Wallet, die nicht vom offiziellen Jetton-Master abgeleitet war, übermittelte erfolgreich eine gefälschte JettonNotify, die von der Bridge als rechtmäßige Einzahlung behandelt und in einen gültigen Cross-Chain-Mint auf TAC EVM umgewandelt wurde. Ein robuster Fix sollte sicherstellen, dass die Bridge auf TON-Seite die Absenderadresse mit der kanonischen Wallet vergleicht, die vom offiziellen Jetton-Master für den beanspruchten Eigentümer und Vermögenswert abgeleitet wurde.

Referenzen

• [1] TAC Build Post-Incident Statement

Boost Hook

Am 13. Mai 2026 wurde Boost, ein Perpetual-Protokoll, das auf einem Uniswap V4 Pool und Hook basiert, auf Ethereum für etwa 46,75 Tsd. USD ausgenutzt. Die Ursache war eine Spotpreis-Manipulation: BoostHook verwendete den slot0 sqrtPriceX96 des V4-Pools direkt als Einstiegspreis beim Öffnen gehebelter Positionen, was es dem Angreifer ermöglichte, den Preis innerhalb einer einzigen Transaktion in die Höhe zu treiben und das Protokoll zu zwingen, PERP-Token zum manipulierten Preis unter Verwendung seiner eigenen ETH-Reserven zu kaufen.

Hintergrund

Boost ist ein Perpetual-Protokoll, das auf einem einzelnen Uniswap V4 ETH/PERP-Pool mit einem benutzerdefinierten Hook (BoostHook) basiert. PERP ist ein ERC-20-Token mit festem Angebot (insgesamt 1 Mio. Token), und Boost fungiert als einziger Liquiditätsanbieter des Pools, indem es sämtliches PERP als konzentrierte Liquiditätsbänder über dem ursprünglichen Preis einspeist.

Der Hebel ist als Markt-Swap gegen denselben Pool implementiert. Wenn ein Nutzer openLong() aufruft, ergänzt BoostHook die Sicherheit des Nutzers, indem es zusätzliches ETH aus seinen eigenen oberen Bändern als geliehenen Betrag abhebt und dann die gesamte Positionsgröße in PERP tauscht. Das PERP verbleibt im Guthaben von BoostHook, und der Nutzer erhält einen internen Position-Datensatz. Das Schließen oder die Liquidation kehrt den Swap um, zahlt Schulden zurück und gibt überschüssiges Kapital zurück.

Schwachstellenanalyse

Der fehlerhafte BoostHook-Vertrag ist unter 0x3db1...d7eacc bereitgestellt.

Die Ursache ist, dass BoostHook den slot0 sqrtPriceX96 des Pools, also den Spotpreis, direkt als Einstiegspreis beim Öffnen einer Position liest. Da slot0 den sofortigen Pool-Zustand widerspiegelt, ist er innerhalb einer einzigen Transaktion durch große Swaps manipulierbar. Es gibt keine Überprüfung, die Erzwingt, dass der Einstiegspreis innerhalb einer manipulationsresistenten Grenze liegt, wie z. B. einem TWAP.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0xb45cc4...cebd3811.

• Schritt 1: Der Angreifer nahm einen WETH-Blitzkredit von Morpho Blue auf und wandelte ihn in ETH um, um das Startkapital für die Manipulationsrunde bereitzustellen.

• Schritt 2: Der Angreifer tauschte eine große Menge ETH gegen PERP über Sat1SwapRouter, wodurch der Spotpreis des Pools nach oben getrieben wurde. Der Angreifer hielt nun eine große PERP-Position, die zum Preis vor dem Pump gekauft wurde.

• Schritt 3: Der Angreifer rief openLong() mit einem 5-fachen Hebel mehrmals auf. Pro Aufruf hinterlegte der Angreifer eine kleine Sicherheit (z. B. 2 ETH), und BoostHook lieh sich das Vierfache dieses Betrags aus seinen eigenen Bändern und kaufte dann mit der vollen Positionsgröße PERP zum manipulierten Spotpreis. Jede aufeinanderfolgende Eröffnung trieb den Spotpreis noch höher, und ein Großteil des Kaufdrucks stammte aus dem ETH des Protokolls selbst.

• Schritt 4: Der Angreifer tauschte das in Schritt 2 erworbene PERP zurück in ETH. Da der Spotpreis sowohl durch den ursprünglichen Pump als auch durch die vom Protokoll finanzierten Eröffnungen in Schritt 3 erhöht wurde, lag der Verkaufspreis deutlich über dem Einstiegspreis. Die Differenz zwischen dem günstigen Kauf und dem teuren Verkauf stellte den Gewinn dar.

• Schritt 5: Innerhalb des afterSwap-Callbacks des Dumps wurde _scanAndLiquidate ausgelöst und begann, die Positionen aus Schritt 3 als uneinbringliche Forderungen gegen das Protokoll zu liquidieren. Dies hatte keinen Einfluss auf den Gewinn des Angreifers, da die Auszahlung aus Schritt 4 bereits abgeschlossen war.

• Schritt 6: Der Angreifer wandelte das angehäufte ETH zurück in WETH, zahlte den Blitzkredit zurück und behielt das verbleibende ETH als Gewinn.

Fazit

Der Vorfall wurde durch eine Spotpreis-Manipulation verursacht: BoostHook verwendete den Spotpreis des V4-Pools direkt als Einstiegspreis für gehebelte Öffnungen, was es dem Angreifer ermöglichte, den Preis innerhalb einer einzigen Transaktion in die Höhe zu treiben und das Protokoll zu zwingen, PERP an der Spitze mit eigenen ETH-Reserven zu kaufen. Ein Fix sollte _swapEthForToken gegen einen manipulationsresistenten Referenzpreis wie einen TWAP beschränken, anstatt dem sofortigen slot0-Wert zu vertrauen.

Über BlockSec

BlockSec ist ein Full-Stack-Anbieter für Blockchain-Sicherheit und Krypto-Compliance. Wir entwickeln Produkte und Dienstleistungen, die Kunden dabei unterstützen, Code-Audits (einschließlich Smart Contracts, Blockchain und Wallets) durchzuführen, Angriffe in Echtzeit abzufangen, Vorfälle zu analysieren, illicit Gelder nachzuverfolgen und AML/CFT-Verpflichtungen über den gesamten Lebenszyklus von Protokollen und Plattformen hinweg einzuhalten.

BlockSec hat zahlreiche Blockchain-Sicherheitspapiere auf angesehenen 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