La faille batchOverflow sur les smart contracts ERC-20 - ce qui s'est passé en 2018

En avril 2018, la startup de sécurité PeckShield a découvert une vulnérabilité critique dans certains smart contracts ERC-20 déployés sur Ethereum. La faille, dite “batchOverflow”, exploitait un dépassement d’entier (integer overflow) dans la fonction batchTransfer pour permettre la création ex nihilo d’un nombre astronomique de jetons. La réaction des exchanges a été immédiate : Poloniex, Changelly, OKEx et Quoine ont suspendu les dépôts et retraits ERC-20.

En bref

• PeckShield a identifié la faille batchOverflow en avril 2018 sur certains smart contracts ERC-20
• L’exploit permettait de générer 57,9 x 10^57 jetons BeautyChain (BEC) depuis une seule transaction
• La fonction batchTransfer n’est pas dans la norme ERC-20 standard, limitant le nombre de tokens affectés
• Poloniex, OKEx, Changelly et Quoine ont suspendu tous les tokens ERC-20 par précaution
• La réponse de l’industrie a accéléré l’adoption de la bibliothèque SafeMath d’OpenZeppelin

Qu’est-ce que la faille batchOverflow et comment fonctionnait-elle ?

La faille batchOverflow exploitait un dépassement d’entier (integer overflow) dans des smart contracts ERC-20 intégrant une fonction non standard nommée batchTransfer. Cette fonction permettait d’envoyer des jetons à plusieurs destinataires simultanément. La vulnérabilité résidait dans le calcul du montant total à transférer : uint256 amount = _value * _receivers.length.

Lorsque _value était un nombre suffisamment grand et _receivers.length égal à 2, le produit dépassait la capacité maximale d’un entier 256 bits non signé, le ramenant à zéro. Le contrat vérifiait que l’émetteur avait suffisamment de fonds en comparant son solde à ce total de zéro, la condition passait, et le montant original (astronomique) était crédité à chaque destinataire. Un attaquant pouvait créer des jetons à partir de rien.

[INTERNAL-LINK: smart contracts Ethereum → guide d’introduction aux smart contracts]

Quels jetons étaient affectés en 2018 ?

Seuls les tokens ayant implémenté la fonction batchTransfer dans leur contrat étaient vulnérables. Cette fonction n’est pas dans la norme ERC-20 standard définie dans l’EIP-20. Elle avait été ajoutée par certaines équipes pour des raisons de confort opérationnel. Le token BeautyChain (BEC) fut le premier cas documenté de l’exploitation réelle de cette faille.

Sur Etherscan, la transaction d’exploit BeautyChain montre que l’attaquant a généré 57,9 x 10^57 jetons BEC, un chiffre si absurde qu’il a immédiatement alerté les observateurs. Le prix de BEC a chuté à zéro ou quasi-zéro sur les exchanges concernés dans les heures suivantes.

[PERSONAL EXPERIENCE] La réaction des exchanges en 2018 fut rapide mais brutale. Poloniex a suspendu tous les dépôts et retraits ERC-20, indépendamment de leur exposition réelle à batchTransfer. C’est une mesure de précaution compréhensible face à l’incertitude, mais elle a affecté des centaines de tokens sains qui n’utilisaient pas cette fonction vulnérable.

Comment les développeurs ont-ils répondu à cette vulnérabilité ?

La réponse principale de l’écosystème a été l’adoption massive de la bibliothèque SafeMath développée par OpenZeppelin. Cette bibliothèque remplace les opérations arithmétiques natives de Solidity par des fonctions qui vérifient systématiquement les débordements et annulent la transaction si un overflow est détecté.

L’écosystème des audits de smart contracts a également pris une importance croissante après 2018. Des firmes comme PeckShield (qui avait découvert batchOverflow), Trail of Bits, Consensys Diligence et Certik ont développé des services d’audit formels devenus standard pour tout projet sérieux avant son déploiement. Les déploiements sans audit sont aujourd’hui fortement déconseillés par la communauté.

[UNIQUE INSIGHT] La faille batchOverflow illustre un principe essentiel de la sécurité des smart contracts : les composants non standards ajoutent de la surface d’attaque. La norme ERC-20 est bien auditée et éprouvée. Chaque ligne de code ajoutée en dehors de la norme crée un vecteur de risque supplémentaire. Les standards Solidity 0.8.x publiés à partir de 2020 intègrent nativement les vérifications d’overflow, éliminant cette classe de bugs pour les nouveaux contrats.

Quelles leçons durables pour la sécurité des tokens en 2026 ?

Depuis 2018, les pratiques de sécurité dans le développement de smart contracts se sont profondément améliorées. Solidity 0.8.x (publié en 2020) a intégré la protection contre les overflows dans le compilateur lui-même, rendant la bibliothèque SafeMath optionnelle pour les nouveaux contrats. Les bugs de type batchOverflow sont devenus rares sur les contrats modernes.

Les incidents de sécurité majeurs ont cependant continué sur d’autres vecteurs : réentrance (rappel du bug du DAO en 2016), manipulation d’oracle de prix dans la DeFi, bugs de logique métier. En 2026, la surface d’attaque s’est déplacée vers les protocoles DeFi complexes et les bridges inter-chaînes, qui restent des zones à risque élevé malgré les progrès en matière d’audit.

[INTERNAL-LINK: sécurité DeFi → article sur les principaux hacks DeFi et leurs mécanismes]

Questions fréquentes

Qu’est-ce que la faille batchOverflow de 2018 ?

La faille batchOverflow était une vulnérabilité dans certains smart contracts ERC-20 utilisant une fonction non standard batchTransfer. Un dépassement d’entier (integer overflow) permettait à un attaquant de créer un nombre illimité de jetons sans avoir le solde correspondant. Le premier exploit documenté fut le token BeautyChain (BEC) en avril 2018, signalé par la société PeckShield.

Tous les tokens ERC-20 étaient-ils affectés en 2018 ?

Non. Seuls les tokens ayant ajouté la fonction batchTransfer à leur contrat étaient vulnérables. Cette fonction ne fait pas partie de la norme ERC-20 standard. Les tokens respectant strictement le standard EIP-20 n’étaient pas concernés. Poloniex et d’autres exchanges ont suspendu tous les ERC-20 par précaution, mais le nombre de tokens réellement vulnérables était limité.

Ce type de faille existe-t-il encore en 2026 ?

Les dépassements d’entier de type batchOverflow sont devenus rares sur les contrats modernes. Solidity 0.8.x, publié en 2020, intègre nativement la vérification des overflows dans le compilateur. Les nouveaux contrats écrits avec Solidity 0.8.x ou supérieur sont protégés par défaut. Les risques actuels se concentrent davantage sur la logique métier des protocoles DeFi et les bridges inter-chaînes.