Un agent d’IA met en évidence jusqu’à 4,6 millions de dollars de pertes potentielles dans les vulnérabilités de smart contracts blockchain

• Des modèles d’IA ont prouvé par simulation qu’il est possible d’exploiter de vraies vulnérabilités de smart contracts blockchain pour faire apparaître jusqu’à 4,6 millions de dollars de pertes potentielles
• L’équipe de recherche a construit le benchmark SCONE-bench pour l’évaluation, basé sur 405 contrats réellement piratés entre 2020 et 2025
• Claude Opus 4.5, Sonnet 4.5 et GPT-5 ont réussi à attaquer 55,8 % des contrats publiés après la date de coupure des connaissances
• Deux modèles ont détecté 2 vulnérabilités zero-day et ont démontré que des attaques autonomes sont techniquement possibles dans des conditions réelles
• Avec l’amélioration rapide des capacités offensives de l’IA, il faut d’urgence privilégier le déploiement de l’IA à des fins défensives

---

SCONE-bench : benchmark d’attaque de smart contracts

• Les chercheurs ont développé SCONE-bench pour quantifier l’impact économique des vulnérabilités de smart contracts
  • Il comprend 405 contrats qui ont réellement été compromis entre 2020 et 2025
  • Collectés sur 3 blockchains : Ethereum, Binance Smart Chain, Base
  • Chaque contrat peut être reproduit dans un environnement de simulation (basé sur Docker)
• Chaque agent d’IA devait, en moins de 60 minutes, trouver une vulnérabilité et générer un script d’attaque augmentant le solde en tokens
• Le benchmark peut aussi être utilisé comme outil de contrôle de sécurité avant le déploiement en production

Principaux résultats expérimentaux

• Parmi les 405 cas au total, 10 modèles d’IA ont attaqué avec succès **207 (51,1 %) **et ont généré 550,1 millions de dollars de dommages simulés
• Sur l’échantillon de 34 contrats exploités depuis mars 2025, Opus 4.5, Sonnet 4.5 et GPT-5 ont réussi 19 attaques (55,8 %)
  • Le préjudice total atteint 4,6 millions de dollars, Opus 4.5 obtenant 4,5 millions à lui seul
• Sonnet 4.5 et GPT-5 ont analysé 2 849 nouveaux contrats et trouvé 2 vulnérabilités zero-day
  • Bénéfice total : 3 694 dollars, coût API de GPT-5 : 3 476 dollars
  • La rentabilité d’une attaque autonome est démontrée

Exemples de vulnérabilités

• Vulnérabilité n°1 : absence du modificateur view sur une fonction en lecture seule, entraînant une inflation de tokens
  • L’attaquant peut gonfler son solde par des appels répétés, pour un gain d’environ 2 500 dollars, jusqu’à un maximum de 19 000 dollars
  • Un white-hat hacker a récupéré les fonds
• Vulnérabilité n°2 : absence de vérification du bénéficiaire des frais, ce qui permet à n’importe quelle adresse de retirer des frais
  • Un attaquant réel a volé l’équivalent de 1 000 dollars en seulement 4 jours

Analyse des coûts

• Le coût d’exécution total de l’agent GPT-5 est de 3 476 dollars, avec un coût moyen par exécution de 1,22 dollar
• Coût moyen par contrat vulnérable : 1 738 dollars, bénéfice moyen : 1 847 dollars, bénéfice net : 109 dollars
• L’utilisation de tokens a baissé de 70,2 % en 6 mois, avec en moyenne une hausse d’efficacité de 23,4 % par génération
  • Avec le même budget, il est possible d’obtenir 3,4 fois plus d’attaques réussies

Conclusion et enseignements

• En un an, le taux de réussite des attaques des agents d’IA est passé de 2 % à 55,88 %, et les dommages simulés de 5 000 dollars à 4,6 millions
• Les profits d’attaque doublent tous les 1,3 mois, tandis que les coûts en tokens baissent de 23 % tous les 2 mois
• Le délai entre le déploiement d’un contrat et son exploitation vulnérable devrait fortement se raccourcir
• Tous les codes logiciels, et pas seulement les smart contracts, peuvent devenir des cibles de l’IA
• La même technologie peut aussi être utilisée pour des agents d’IA défensifs, renforçant l’importance de l’automatisation de la sécurité basée sur l’IA

[GN⁺]

Commentaire Hacker News

• Notre startup développe des agents de test d’intrusion
  Nous misons sur cette direction depuis plus d’un an, depuis que les modèles ont commencé à vraiment bien coder
  Le passage de Sonnet 4 à 4.5 a été un saut de performance énorme, et nous testons actuellement Opus 4.5 en interne
  C’est la première version d’Opus suffisamment abordable pour un usage en production, donc nous sommes en train de repenser notre système de benchmark car nous saturons presque nos cas de test

  • J’ai moi aussi déjà essayé l’analyse statique des vulnérabilités de sécurité dans du code avec des LLM
    Mais Anthropic tient le cœur de la technologie, donc je ne sais pas si créer une startup dans ce domaine a vraiment du sens
    Si l’on se lançait dans un tel contexte, je me demande si la bonne stratégie ne serait pas de croître très vite puis sortir avant que le marché ne comprenne
  • Cette génération de modèles (Opus 4.5, GPT 5.1, Gemini Pro 3) constitue selon moi la plus grande percée depuis gpt-4o
    Avant, ils ne fonctionnaient bien que sur des frameworks familiers comme Python ou Next.js, mais désormais ils gèrent aussi de nouveaux frameworks,
    corrigent eux-mêmes les erreurs de lint ou le débogage, et leur prix est assez réaliste pour des usages variés
  • Je me demande comment ils poussent des modèles de production publics vers le développement d’exploits
    D’après mon expérience, les résultats étaient irréguliers, et si l’utilisateur obtient une réponse du type « Je ne peux pas vous aider », cela doit être problématique pour une startup
  • Je dirige une startup de logiciels pour l’hôtellerie ; si tu veux montrer à quel point ton agent fonctionne bien,
    tu peux me trouver sur rook (comme la pièce d’échecs) hotel.com

• Je ne comprends absolument pas ce graphique
  Je ne vois même pas ce qu’il essaie de dire, et l’affirmation de « linéarité » me paraît peu étayée
  La mention de « $4.6M de fonds simulés volés » donne l’impression qu’ils ont ciblé des contrats vulnérables déjà connus
  Du coup, le titre paraît un peu faible

• L’équipe de recherche précise qu’elle n’a pas testé cela sur une vraie blockchain
  C’est censé éviter des dommages réels, mais ça enlève un peu d’impact
  Cela me rappelle l’ancien piratage d’Ethereum où « les bons hackers ont d’abord volé l’argent avant de le rendre ensuite »

  • L’affaire du fork d’Ethereum à l’époque était vraiment ironique
    On disait : « Nous sommes une monnaie immuable sans banque ni régulation », puis,
    quand des personnes importantes ont perdu de l’argent, il a finalement fallu le récupérer, donc ils ont agi comme une banque
  • Il est peut-être déjà possible que quelqu’un analyse la sécurité des smart contracts avec de l’IA en conditions réelles
    J’imagine une structure où l’on injecte de la puissance GPU, et en sortie on obtient des exploits et des cryptomonnaies
  • L’article n’explique pas comment il a « supposé » le nombre de victimes, ce qui me laisse perplexe
    Si l’on dépense $3,500 en tokens IA pour corriger un bug qui vaut $3,600, on ne sait pas non plus très bien qui doit absorber ce coût
    Au final, cela ressemble à un message marketing d’Anthropic — du genre « changez le monde avec nos modèles »
  • Un vrai cyberpunk serait probablement revenu au cash anonyme

• La phrase « deux agents ont trouvé une vulnérabilité zero-day et créé un exploit d’une valeur de $3,694 » apparaît tout en haut de l’article

  • Mais il faudrait aussi inclure le coût du travail des développeurs pour obtenir un chiffre réaliste
    Mettre ce genre de formule au premier plan de la PR me paraît être un choix assez risqué

• J’ai regardé une vidéo de présentation liée au concours DARPA AIxCC,
  et vu le niveau actuel, ce genre de résultat n’a plus rien de surprenant

• Quelqu’un demandait si on pouvait lui expliquer les smart contracts
  Il disait comprendre la structure « if X happens, then Y », mais se demandait si ce n’était pas manipulable selon qui renseigne X

  • Un smart contract « pur » traite automatiquement des transactions simples comme un échange de tokens
    Par exemple, tu donnes 100 tokens apple et tu reçois 50 tokens pear
    Dans une forme plus complexe, on peut aussi faire de la distribution de fonds basée sur un vote
    Mais les informations sur le monde extérieur (par exemple un résultat d’élection) doivent être fournies via un oracle
  • Il n’y a pas toujours des entrées externes
    Par exemple, un contrat du type « si l’adresse A dépose X coins, alors elle reçoit Y coins depuis l’adresse Y »
    comporte une logique de vérification qui rend toute manipulation arbitraire impossible
    En revanche, dès qu’on traite d’événements du monde réel (off-chain), la question des oracles introduit un problème de confiance
  • Un contrat une fois déployé est un code immuable, donc il faut absolument vérifier sa structure d’autorisations avant utilisation
    Dans des cas comme les contrats proxy, qui peuvent pointer vers un autre code, on utilise parfois un timelock pour renforcer la confiance
    Les oracles off-chain exigent toujours un certain niveau de confiance
  • Une blockchain est un environnement isolé qui ne connaît que ses propres données
    Pour utiliser des données externes, il faut un oracle,
    et on peut en apprendre davantage dans l’introduction de Chainlink aux oracles
  • Il ne faut pas conclure ce type de contrat avec des personnes non fiables
    Des escrocs peuvent laisser des failles dans le code pour détourner les fonds
    Les contrats légitimes empêchent ce genre d’actes, mais les vecteurs d’attaque sont infinis

• La conclusion selon laquelle « l’IA peut réellement mener des exploits autonomes rentables »
  me semble faire un saut logique lorsqu’elle débouche sur « il faut adopter activement l’IA en défense »

  • Mais du point de vue d’un développeur de smart contracts, disposer d’un outil automatique de détection de vulnérabilités puissant et peu coûteux serait clairement très utile

• La formule « nous avons établi une borne inférieure des dommages économiques »
  revient en fait à parler d’efficience du marché, non ?

• Sur notre projet aussi, on observe déjà des comportements d’auto-amélioration
  L’étape suivante semble naturellement être celle des agents auto-améliorants
  C’est assez fascinant d’être en plein milieu de cette évolution

• Le fait que l’équipe de recherche précise qu’elle n’a pas testé cela sur une vraie blockchain
  est presque drôle, car cela semble au contraire avoir servi de catalyseur pour pousser les gens à entrer dans une course à l’usage des modèles