~11,3 Mio. $ verloren: Multicall Router, Nostra

In der vergangenen Woche (14.09.2026 – 20.09.2026) haben wir 2 Sicherheitsvorfälle mit einem geschätzten Gesamtschaden von etwa 11,3 Mio. USD beobachtet.

Datum	Vorfall	Typ	Geschätzter Schaden
2026/09/15	Unknown Multicall Router	Unzureichende Zugriffskontrolle	~7,8 Mio. USD
2026/09/17	Nostra Finance	Fehlerhafte Oracle-Konfiguration	~3,5 Mio. USD

Wochenhighlight: Unknown Multicall Router

Dieser Vorfall wurde ausgewählt, weil eine subtile Änderung der Aufrufer-Identität über verschachtelte Router-Aufrufe hinweg die Autorisierung eines Safe-Wallets, das benutzerdefinierte Module ausführte, aushebelte und eine erhebliche Vermögensabhebung ermöglichte.

Am 15. September 2026 kam ein MEV-Bot mit dem Namen Yoink einem versuchten Exploit gegen ein Safe-Wallet zuvor, das seine Vermögenswerte über benutzerdefinierte Strategiemodule verwaltete, was zu einem geschätzten Verlust von etwa 7,8 Mio. USD führte [1]. Anfragen erreichten diese Module über einen Multicall-Router, bei dem ein Autorisierungsfehler bei verschachtelten Aufrufen es ermöglichte, dass nicht vertrauenswürdige Anweisungen in die Modulkette gelangten, während eine wiederverwendbare Berechtigung dem unautorisierten Vorgang zusätzlich Vorschub leistete.

Hintergrund

Ein Safe-Wallet kann ein Safe-Modul aktivieren. Sobald aktiviert, kann das Modul execTransactionFromModule() aufrufen, um das Wallet zur Ausführung von Vorgängen ohne Multisig-Genehmigung anzuweisen. Ein aktiviertes Modul stellt somit eine dauerhafte Berechtigung über die Vermögenswerte des Wallets dar. Das betroffene Safe-Wallet hatte zwei Strategiekomponenten aktiviert, das Gateway-Modul und das LP-Modul.

Das Gateway-Modul definierte wiederverwendbare Befehlsvorlagen, von denen jede einen Vorgang beschrieb, den das betroffene Safe-Wallet ausführen durfte, wobei die konkreten Werte zur Ausführungszeit eingesetzt wurden. Es akzeptierte Befehle nur von Aufrufern auf seiner eigenen Liste autorisierter Aufrufer. Jede Ausführung musste zudem einen Merkle-Beweis mitführen, der gegen eine gespeicherte Wurzel geprüft wurde und die aufgerufene Befehlsvorlage authentifizierte. Einige Vorlagen wiesen das Wallet an, das LP-Modul aufzurufen, das Uniswap-v4-Liquiditätsoperationen mit den Vermögenswerten des Wallets durchführte. Die Kontrolle kehrte daher über das Wallet selbst zurück, anstatt direkt von einem Modul zum nächsten weitergegeben zu werden:

Authorized Caller
       |
       v
Gateway module -- verify(command, Merkle proof, root)
       |
       | execTransactionFromModule(...)
       v
Safe wallet context
       |
       v
   LP module --> mintPosition(...)

Die Akteure in diesem Vorfall riefen das Gateway-Modul nicht direkt auf. Anfragen kamen über einen Multicall-Router an, der Sammelaufrufe in ihrem Namen weiterleitete. Da der Router immer dann der direkte Aufrufer war, wenn er eine legitime Anfrage weiterleitete, enthielt die Liste autorisierter Aufrufer des Gateway-Moduls den Router selbst.

Über diesen Pfad konnte das betroffene Safe-Wallet aEthrsETH, das Aave-Empfangstoken für hinterlegtes rsETH, in einen Uniswap-v4-Pool einzahlen und dabei ein Positions-NFT an das Wallet zurück minten. Jeder Inhaber von aEthrsETH konnte dieses über Aave verbrennen, um das zugrunde liegende rsETH abzuheben.

Das betroffene Safe-Wallet hatte gegen diese Aave-Sicherheit auch Kredite aufgenommen. Aave verfolgte daher für das Wallet einen Health-Faktor, das Verhältnis des Wertes seiner Sicherheiten zu seinen Schulden, und lehnt einen Transfer von Sicherheiten ab, der diesen Faktor unter 1 fallen ließe.

Schwachstellenanalyse

Der Router unter 0x4f00...8ebC ist nicht quellcode-verifiziert. Die folgende Darstellung stützt sich daher auf seinen bereitgestellten Bytecode, dekompilierte Logik, Transaktionsspuren und eine öffentliche Fork-Test-Rekonstruktion anstelle maßgeblicher Bezeichnungen auf Quellcode-Ebene.

Die Dispatch-Logik des Routers akzeptierte ein Ziel, das entweder auf seiner Zulassungsliste stand oder die eigene Adresse des Routers war, und prüfte anschließend die Liste autorisierter Aufrufer dieses Ziels gegen den msg.sender des aktuellen Aufrufs. Nichts bewahrte die Identität des ursprünglichen externen Aufrufers über einen Aufruf hinweg, den der Router an sich selbst richtete.

Wenn der Router sich selbst aufrief, nahm der innere Aufruf den Router als msg.sender wahr. Der Autorisierungs-Helfer akzeptierte den Router im Fall des Selbstziels und prüfte andernfalls, ob der aktuelle msg.sender auf der Liste autorisierter Aufrufer des nächsten Ziels erschien. Folglich wurde ein innerer Aufruf, der auf das Gateway-Modul zielte, so bewertet, als stamme er vom bereits autorisierten Router und nicht vom externen Aufrufer. Dies ermöglichte es Anweisungen aus einer nicht vertrauenswürdigen Quelle, die Aufrufer-Autorisierung des Gateways über den verschachtelten Pfad zu erfüllen.

Ein zweiter Fehler lag in der Beweisprüfung selbst. Der Beweis authentifizierte die Befehlsvorlage, aber keine Prüfung band die zusammen mit ihr übermittelten Laufzeitparameter ein. Ein gültiger Beweis, der für einen früheren legitimen Befehl ausgestellt worden war, blieb daher auch dann nutzbar, nachdem seine konkreten Ausführungswerte geändert worden waren. Der wiederverwendete Beweis lieferte eine nutzbare Berechtigung, doch erst die Umgehung der verschachtelten Autorisierung ermöglichte es einem nicht vertrauenswürdigen Aufrufer überhaupt, das Gateway-Modul zu erreichen.

Angriffsanalyse

Ein zuvor ausgestellter Merkle-Beweis für dieselbe Befehlsvorlage blieb mit abweichenden Laufzeitwerten nutzbar. Diese Eigenschaft umging die Aufrufer-Autorisierung des Gateways nicht eigenständig, lieferte jedoch eine nutzbare Berechtigung, nachdem der verschachtelte Router-Pfad diese Autorisierungsprüfung erfüllt hatte.

Die folgende Analyse basiert auf der Transaktion 0x0e7680...a8705.

Vor der erfolgreichen Transaktion setzte der ursprüngliche Angreifer einen Angriffsvertrag, ein vom Angreifer kontrolliertes PAT-Token sowie einen zweiten Vertrag ein, der später den PAT-Swap durchführen sollte.

Im darauffolgenden Block rief der Angreifer prepare() auf, um einen PAT/aEthrsETH-Uniswap-v4-Pool zu erstellen und zu initialisieren.

Der Yoink-MEV-Bot erkannte den bevorstehenden Exploit und kam dem ursprünglichen Angreifer zuvor, indem er den vorbereiteten Angriffsvertrag aufrief. Der resultierende Aufruf gelangte in den Router, veranlasste den Router, sich selbst aufzurufen, und erreichte dann das Gateway-Modul mit dem Router als msg.sender. Als aktiviertes Modul konnte das Gateway daraufhin das betroffene Safe-Wallet dazu veranlassen, den übermittelten Vorgang ohne Multisig-Genehmigung auszuführen.

Die Anweisung veranlasste das betroffene Safe-Wallet, etwa 2.900 aEthrsETH als Liquidität in den vom Angreifer kontrollierten PAT/aEthrsETH-Pool einzubringen, innerhalb des Tick-Bereichs [10, 20]. Die Transaktion mintete zudem das zugehörige Uniswap-v4-Positions-NFT an das Wallet, wodurch der Vorgang innerhalb des erwarteten Liquiditätsflusses erschien. Dies erschöpfte nicht den gesamten aEthrsETH-Bestand des Wallets: Der Betrag war so begrenzt, dass Aaves Health-Faktor-Prüfung weiterhin bestanden wurde, wobei das Wallet einen Health-Faktor von 1.001182484056805114 behielt.

Der Angriffsvertrag tauschte anschließend vom Angreifer kontrolliertes PAT gegen nahezu das gesamte eingezahlte aEthrsETH über diesen zweiten Vertrag. Er verbrannte die erlangten Empfangstoken über Aave und hob den entsprechenden Betrag an rsETH ab. Von den etwa 2.900 rsETH, die beim Yoink-Bot ankamen, gingen etwa 2.882,37 rsETH an dessen Gewinnempfänger, während etwa 17,63 rsETH gegen ETH getauscht wurden, wobei nahezu das gesamte resultierende ETH an den Block-Builder gezahlt wurde.

Fazit

Die Grundursache war ein Autorisierungsfehler in benutzerdefinierter Infrastruktur, die an ein einzelnes Safe-Wallet angebunden war, verschärft durch eine Berechtigung, die nicht alle Ausführungsparameter einband. Er sollte nicht den Kernverträgen von Safe, Aave, Uniswap v4 oder Kelp zugeschrieben werden.

Eine Komponente, die Aufrufe im Namen anderer weiterleitet, sollte die Autorisierung anhand des ursprünglichen externen Aufrufers entscheiden, nicht anhand einer Identität, die die Aufrufkette unterwegs annimmt, und sie sollte nicht als eigenes Ziel erreichbar sein. Eine Berechtigung sollte ebenso die konkreten Werte einbinden, mit denen ein Vorgang ausgeführt wird, und nicht nur die Vorlage, zu der dieser Vorgang gehört.

Weitere Vorfälle dieser Woche

Nostra Finance

Am 17. September 2026 wurde Nostras Geldmarkt auf Starknet durch einen künstlich überhöhten NSTR-Oracle-Preis ausgenutzt, wodurch etwa 3,5 Mio. USD an Vermögenswerten gegen überbewertete Sicherheiten geliehen werden konnten. Die Grundursache war eine Oracle-Integrationskonfiguration, die zu wenige Preisquellen akzeptierte, sodass ein manipuliertes Kursangebot aus einem dünnen Pool den aggregierten Preis erheblich beeinflussen konnte. Nostra pausierte seine Märkte [2], während Pragma berichtete, dass die Adresse des Angreifers eingefroren worden sei und die Wiederherstellungsarbeiten liefen [3]. Der endgültige Verlust und mögliche Wiederherstellungen blieben unbekannt.

Hintergrund

Nostra betrieb einen Geldmarkt auf Starknet, auf dem Nutzer unterstützte Sicherheiten hinterlegen und andere Vermögenswerte entsprechend dem aus dem Oracle abgeleiteten Wert der Sicherheiten leihen konnten.

Nostra bezog NSTR-Preisdaten über seinen eigenen Preisfeed-Vertrag, der an einen Haupt-Oracle-Vertrag delegierte, der wiederum von Pragma las, einem Oracle, das aggregierte Preise auf Starknet veröffentlicht. Publisher übermittelten Beobachtungen an Pragma unter benannten Quellen, darunter AVNU und GECKOTERMINAL, und die dokumentierte NSTR-Konfiguration beschrieb einen Median über drei davon [4][5]. Jede Oracle-Antwort enthielt einen Preis, eine Dezimalgenauigkeit, einen Zeitstempel und eine Anzahl beitragender Quellen [6]. Der Haupt-Oracle-Vertrag speicherte MinAggregatedSources, eine konfigurierbare Mindestanzahl beitragender Quellen.

Die eingesetzte Aggregationsimplementierung wurde nicht direkt eingesehen. Zwei unabhängige Indizien weisen dennoch in dieselbe Richtung: Pragmas Open-Source-Code liefert immer dann den Durchschnitt der beiden mittleren Einträge, wenn die Anzahl der Einträge gerade ist [6], und die bei diesem Vorfall beobachtete MEDIAN-Antwort entsprach dem arithmetischen Mittel ihrer beiden beitragenden Beobachtungen.

Die Zahlen hinter diesen Quellen stammten aus dem Markt. Eine GECKOTERMINAL-Beobachtung konnte aus On-Chain-Pools abgeleitet werden, und einer dieser Handelsplätze auf Starknet ist Ekubo, eine dezentrale Börse, die konzentrierte Liquidität nutzt, ähnlich wie Uniswap v3. Liquiditätsanbieter platzieren Vermögenswerte innerhalb ausgewählter Tick-Bereiche, und Swaps bewegen den Pool-Preis durch aktive Bereiche, während Lücken ohne aktive Liquidität Positionen trennen können, die zu deutlich unterschiedlichen Preisen platziert wurden.

Nostra verwendete den über diesen Oracle-Pfad bezogenen NSTR-Preis, um hinterlegte Sicherheiten zu bewerten und die Kreditkapazität des Kontos zu berechnen.

Schwachstellenanalyse

Nostras Geldmarkt las NSTR-Preise von 0x6838...5bf0, dem Vertrag, den die Dokumentation als NSTR-Preisfeed aufführt [7]. Dieser Vertrag delegierte an den von ihm bestimmten Haupt-Oracle, 0x7b05...f0ab, bei dem MinAggregatedSources auf 1 konfiguriert war. Pragma empfiehlt mindestens drei Preisquellen und berichtete nach dem Vorfall, dass ein durchgesetztes Minimum von drei Quellen die hier akzeptierte Antwort abgelehnt hätte [3].

Eine Antwort mit zwei gültigen Beobachtungen überschritt somit den konfigurierten Schwellenwert. Da die MEDIAN-Berechnung für zwei Beobachtungen auf deren arithmetisches Mittel hinauslief, konnte ein einzelnes extremes Kursangebot das Ergebnis erheblich verzerren, selbst wenn die andere Beobachtung nahe am vorherrschenden Marktpreis blieb.

Dies war eine Schwäche in der Integrationskonfiguration und kein Fehler bei der Dezimalskalierung oder in der Median-Implementierung. Pragma stellte in keiner der beiden Berechnungen einen Defekt fest [3]. Der unzureichende Quellen-Schwellenwert ermöglichte es, dass die korrekt berechnete Ausgabe aus einem unzureichend diversifizierten Eingabesatz den Wert der Sicherheiten und die Kreditkapazität bestimmte.

Angriffsanalyse

Der Angriff beruhte auf der Manipulierbarkeit eines neu erstellten, gering finanzierten Pools mit konzentrierter Liquidität. Verfügbare Beweise deuten darauf hin, dass die vom Angreifer vorgenommene Bestückung des Pools und die wiederholte Aktivität den für die GECKOTERMINAL-Beobachtung verwendeten Pool beeinflusst haben könnten, wobei der genaue kausale Zusammenhang bei der Pool-Auswahl jedoch nicht abschließend geklärt ist.

Die folgende Analyse basiert auf der Transaktion 0x2460fd...cdf00e.

Der Angreifer erstellte zunächst einen Ekubo-Pool NSTR/SolvBTC und stellte 1,5 SolvBTC als einseitige Liquidität in einem niedrigeren, inaktiven Preisbereich bereit. Anschließend fügte der Angreifer etwa 1.900 NSTR und 0,0001514751 SolvBTC um den normalen Marktpreis herum hinzu und führte im Pool wiederholte Swaps durch.

Als Nächstes platzierte der Angreifer 190 NSTR als einseitige Liquidität in einem engen Bereich weit über dem normalen Preis. Nach dem Entfernen der Liquidität um den normalen Marktpreis herum ließ der Angreifer eine liquiditätsfreie Lücke vor dieser hochpreisigen Position bestehen.

Ein Swap mit lediglich 0,00000001 SolvBTC überquerte die leere Spanne und bewegte den Pool zum Tick -6645400, an die Grenze der hochpreisigen Position. Der manipulierte Pool-Wert wurde anschließend als GECKOTERMINAL-Beobachtung für NSTR/USD in Höhe von 99,02439975 USD übermittelt.

Die andere beitragende Beobachtung, übermittelt unter AVNU, bewertete NSTR mit 0,00596118 USD. Keine Beobachtung der dritten konfigurierten Quelle erscheint in dieser Antwort, sodass diese beiden die einzigen Werte waren, die in die Aggregation einflossen [4].

Mit zwei Werten war die MEDIAN-Antwort deren arithmetisches Mittel, etwa 49,51518046 USD pro NSTR. Nostra akzeptierte die resultierende Bewertung und behandelte die NSTR-Einlage des Angreifers als ausreichende Sicherheit für eine erhebliche Kreditaufnahme.

Bei der ersten identifizierten Entnahme verwendete der Angreifer ein separates Konto mit NSTR-Sicherheiten, um zu der überhöhten Bewertung etwa 939,386010 ETH zu leihen [4]. Nostra berichtete, dass die vollständige Kreditaufnahme-Sequenz auch STRK, USDC, USDT, WBTC und DAIv1 umfasste, mit einem geschätzten Gesamtkreditwert von etwa 3,5 Mio. USD [2].

Fazit

Der Vorfall resultierte aus einem unzureichenden Schwellenwert für Oracle-Quellen in Nostras Integration, nicht aus einem Fehler in Pragmas Dezimalverarbeitung oder Aggregationsberechnung. Eine Antwort mit zwei Quellen blieb gültig, obwohl eine Beobachtung aus einem stark manipulierbaren Pool stammte.

Nostra sollte ein Minimum von mindestens drei beitragenden Preisquellen durchsetzen und jede Oracle-Antwort ablehnen, deren Quellenanzahl unter diesem Schwellenwert liegt, bevor der Preis zur Bewertung von Sicherheiten oder zur Kreditvergabe verwendet wird. Die Zulassungsfähigkeit von Sicherheiten und Engagementsgrenzen sollten zudem die verfügbare Marktliquidität sowie die Tiefe widerspiegeln, die erforderlich ist, um die zugrunde liegenden Preisquellen jedes Vermögenswerts zu manipulieren.

Quellen

[1] https://x.com/Phalcon_xyz/status/2099741447776096270

[2] https://x.com/nostrafinance/status/2100577538053493076

[3] https://www.pragma.build/updates/nostra-nstr-incident

[4] https://x.com/Phalcon_xyz/status/2100818035082952751

[5] https://www.pragma.build/asset/NSTR-USD?network=mainnet

[6] https://github.com/Astraly-Labs/pragma-oracle

[7] https://docs.nostra.finance/lend-and-borrow/deployed-contracts/money-market-mainnet

Über BlockSec

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

BlockSec hat mehrere Blockchain-Sicherheitspapiere auf renommierten Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe auf DeFi-Anwendungen gemeldet, mehrere Hacks blockiert, um mehr als 20 Millionen Dollar zu retten, und Kryptowährungen im Wert von Milliarden Dollar abgesichert.