Notional Finance piraté : un attaquant vole 1,73 million de dollars via une faille de débordement

Le protocole de prêt décentralisé Notional Finance a été victime d’une attaque le 4 septembre 2026, au cours de laquelle l’attaquant a réussi à dérober environ 1,73 million de dollars. La société de sécurité SlowMist a analysé l’incident dans son intégralité et désigne un dépassement de capacité (integer overflow) dans le calcul de la garantie comme cause du problème. En raison d’une erreur de conversion de type, l’attaquant a pu ouvrir une position non couverte que le protocole considérait comme sûre.

En bref :

• L’attaquant exploite un dépassement de capacité dans le calcul de la garantie de Notional Finance et dérobe 1,73 million de dollars.
• L’erreur se situait dans la fonction qui convertit les engagements en ETH : une valeur de -2^128 a été convertie en 0 par une troncature de type.
• SlowMist recommande de valider les résultats de la fonction abs() et d’utiliser SafeCast pour ce type de calculs.

Comment s’est déroulée l’attaque

L’attaquant a commencé par déployer des contrats auxiliaires et par octroyer des approbations via setApprovalForAll sur les contrats de négociation ERC-1155 de Notional Finance. Deux transferts stratégiquement choisis ont ensuite suivi.

Le premier transfert concernait une paire fCash d’un montant de 1, avec une échéance au 4 septembre 2026. Ce montant était si faible qu’il s’arrondissait à zéro lors de la conversion en ETH, ce qui permettait au contrôle de la garantie de se dérouler sans encombre. Le deuxième transfert utilisait un montant de uint128.max, mais avec une autre échéance : le 3 décembre 2026. Comme les deux engagements relevaient de catégories différentes, ils n’étaient pas additionnés et un dépassement de capacité via SafeMath ne pouvait pas se produire.

Lors du contrôle de la garantie disponible, le système additionnait les deux engagements, ce qui donnait -2^128. Lors de la conversion en ETH, ce nombre était ramené à 0 par une troncature de type, si bien que le protocole jugeait le compte financièrement sain. L’attaquant a ensuite réparti la position importante entre deux contrats auxiliaires, qui ont alors reçu les fCash « receiver ».

Dans une seconde transaction, l’attaquant a clôturé les deux positions, augmentant ainsi les soldes en espèces dans l’Escrow, puis a finalement retiré le gain.

Cause technique : une troncature de type sans contrôle

Selon SlowMist, le cœur du problème se trouve dans la fonction ExchangeRate._convertToETH. Celle-ci exécute un uint128(balance.abs()) en Solidity 0.6.x sans vérifier si le résultat se situe dans la plage valide. Lorsque l’engagement est de -2^128, la valeur absolue est de 2^128, ce qui, après troncature vers le type 128 bits, donne tout simplement 0. Le protocole constate alors un solde de garantie au minimum égal à zéro et autorise la position, alors qu’en réalité il n’existe aucune couverture.

Une erreur comparable, où un calcul incorrect des soldes a conduit à une perte injustifiée, s’était également produite auparavant chez Reddio, qui a perdu 925 ETH à cause d’une faille de double comptage dans ses coffres.

Recommandations de SlowMist

SlowMist affirme qu’une conversion de type réussie ne garantit pas pour autant une évaluation correcte de la valeur. L’équipe de sécurité recommande de refuser tout résultat de abs() qui dépasse type(uint128).max, d’utiliser SafeCast et de tester explicitement les valeurs limites telles que uint128.max et -2^128.

La leçon plus large que tire SlowMist : un solde de garantie nul ou supérieur ne signifie pas automatiquement que la garantie est réellement présente. Les protocoles qui travaillent avec des types de calcul à largeur fixe courent un risque si les valeurs d’entrée extrêmes ne sont pas rejetées au préalable.