Notional Finance gehackt: Angreifer stiehlt $1,73 Millionen durch Überlauffehler

Das dezentrale Kreditprotokoll Notional Finance ist am 4. September 2026 Opfer eines Angriffs geworden, bei dem der Angreifer rund 1,73 Millionen Dollar erbeuten konnte. Das Sicherheitsunternehmen SlowMist hat den Vorfall vollständig analysiert und macht einen Integer Overflow in der Sicherheitenberechnung als Ursache aus. Durch einen Fehler bei der Typkonvertierung konnte der Angreifer eine ungedeckte Position eröffnen, die das Protokoll als sicher einstufte.

In Kürze:

Angreifer nutzt einen Overflow in der Sicherheitenberechnung von Notional Finance aus und stiehlt 1,73 Millionen Dollar.
Der Fehler steckte in der Funktion, die Verbindlichkeiten in ETH umrechnet: Ein Wert von -2^128 wurde durch Typabschneidung auf 0 gesetzt.
SlowMist empfiehlt, Ergebnisse von abs() zu validieren und SafeCast bei solchen Berechnungen zu verwenden.

So lief der Angriff ab

Der Angreifer begann mit dem Ausrollen von Hilfsverträgen und dem Einrichten von Genehmigungen über setApprovalForAll auf den ERC-1155-Handelsverträgen von Notional Finance. Danach folgten zwei strategisch gewählte Übertragungen.

Die erste Übertragung betraf ein fCash-Paar mit einem Betrag von 1 bei einem Fälligkeitsdatum am 4. September 2026. Dieser Betrag war so klein, dass er bei der Umrechnung in ETH auf null abrundete, wodurch die Sicherheitenprüfung ohne Probleme durchlief. Die zweite Übertragung nutzte einen Betrag von uint128.max, allerdings bei einem anderen Fälligkeitsdatum: dem 3. Dezember 2026. Da die beiden Verbindlichkeiten in verschiedene Kategorien fielen, wurden sie nicht zusammengerechnet und ein Overflow über SafeMath konnte nicht auftreten.

Bei der Prüfung der freien Sicherheiten addierte das System die beiden Verbindlichkeiten, was -2^128 ergab. Bei der Umrechnung in ETH wurde diese Zahl durch eine Typabschneidung auf 0 verkürzt, sodass das Protokoll das Konto als finanziell gesund einstufte. Der Angreifer teilte anschließend die große Position auf zwei Hilfsverträge auf, die danach die Receiver-fCash erhielten.

In einer zweiten Transaktion schloss der Angreifer beide Positionen, erhöhte damit die Barguthaben im Escrow und zog schließlich den Gewinn ab.

SlowMist_Team @SlowMist_Team

🚨 On September 4, 2026, the well-known decentralized lending protocol @NotionalFinance was attacked, resulting in a loss of approximately $1.73 million. The SlowMist Security Team has fully analyzed the incident.

🧩 Attack flow:

1️⃣ In a preceding transaction, the attacker deployed auxiliary contracts and called setApprovalForAll on ERC1155Trade to authorize them, after querying two CashMarket maturities and the required AssetIds.
2️⃣ First safeTransferFrom: minted an fCash pair with amount 1 (maturity Sep 4, 2026). The position was too small and rounded to 0 in ETH terms, so the free-collateral check passed.
3️⃣ Second safeTransferFrom: minted an fCash pair with amount uint128.max at a different maturity (Dec 3, 2026), so the two liabilities would not be added in the same bucket and revert under SafeMath.
4️⃣ mintfCashPair then checked free collateral. The two liabilities summed to -2^128, overflowed to 0 when converted to ETH, and the protocol treated the account as healthy.
5️⃣ Receiving contract 2 split the large claim to two auxiliary contracts. The payer was now contract 2, which already held a positive claim, so the check passed and the two contracts received receiver fCash.
6️⃣ In a second transaction, the attacker settled those two positions, increasing the cash balances in Escrow, then called withdraw to realize the profit.

⚙️ Root Cause: ExchangeRate._convertToETH does uint128(balance.abs()) on Solidity 0.6.x with no range check. When the liability is -2^128, 2^128 truncates to 0, so mintfCashPair only sees free collateral ≥ 0 and allows an unbacked position.

🔒 SlowMist Insight: A successful cast is not a successful valuation. Reject any abs() result above type(uint128).max, use SafeCast, and test extremes such as uint128.max and -2^128. Collateral ≥ 0 is not the same as collateral that is real.

Full analysis👇
https://t.co/pwmdNkQOSr

7 Sept 2026View full tweet on X ›

Technische Ursache: Typabschneidung ohne Kontrolle

Laut SlowMist liegt der Kern des Problems in der Funktion ExchangeRate._convertToETH. Diese führt ein uint128(balance.abs()) in Solidity 0.6.x aus, ohne zu prüfen, ob das Ergebnis innerhalb des gültigen Bereichs liegt. Wenn die Verbindlichkeit -2^128 beträgt, ergibt der absolute Wert 2^128, was bei der Abschneidung auf den 128-Bit-Typ schlicht 0 liefert. Das Protokoll sieht dann ein Sicherheitenguthaben von mindestens null und erlaubt die Position, obwohl es in Wirklichkeit keine Deckung gibt.

Ein ähnlicher Fehler, bei dem eine fehlerhafte Berechnung von Guthaben zu ungerechtfertigten Verlusten führte, ereignete sich zuvor auch bei Reddio, das 925 ETH durch eine Doppelzählungslücke in seinen Vaults verlor.

Empfehlungen von SlowMist

SlowMist stellt fest, dass eine erfolgreiche Typkonvertierung noch keine korrekte Wertermittlung garantiert. Das Sicherheitsteam empfiehlt, jedes Ergebnis von abs() abzulehnen, das über type(uint128).max liegt, SafeCast zu verwenden und Grenzwerte wie uint128.max und -2^128 explizit zu testen.

Die breitere Lehre, die SlowMist zieht: Ein Sicherheitenguthaben von null oder höher bedeutet nicht automatisch, dass die Sicherheiten tatsächlich vorhanden sind. Protokolle, die mit Rechentypen fester Breite arbeiten, laufen Gefahr, wenn extreme Eingabewerte nicht im Vorfeld abgewiesen werden.

Keine Finanzberatung. Blockchain Stories bietet ausschließlich informative Inhalte. Krypto-Assets sind sehr volatil und Sie können Ihren gesamten Einsatz verlieren. Führen Sie stets Ihre eigene Recherche durch. Lesen Sie unseren vollständigen Haftungsausschluss.

Affiliate-Hinweis. Einige Links auf dieser Seite sind Affiliate-Links. Wenn Sie sich über einen solchen Link bei einem Partner anmelden, erhalten wir möglicherweise eine Provision, ohne zusätzliche Kosten für Sie. Dies beeinflusst niemals unsere Berichterstattung. Lesen Sie unsere redaktionellen Richtlinien.