Les hacks de 2026 n'attaquent plus le contrat, mais le périmètre

Dans les quatre plus grands vols DeFi de 2026, le contrat intelligent audité n'a pas failli une seule fois. Ce sont la configuration d'un pont, les nœuds alimentant un vérificateur, les agents de IA avec permissions de transfert et la chaîne d'outils du développeur qui ont cédé. Le code qui garde l'argent — celui que l'on audite, que l'on publie et que l'on examine ligne par ligne — a résisté ; ce qui a lâché, c'est le périmètre qui l'entoure : l'infrastructure. Avril 2026 a été le pire mois de l'histoire de la DeFi avec 606 millions de dollars volés, et presque tout cet argent est sorti par la porte de service, non par la serrure blindée de l'entrée. Cet article défend une thèse : en 2026, le locus de l'attaque s'est déplacé hors du contrat. Nous l'argumentons avec les incidents publics de l'année, expliquons pourquoi le périmètre est structurellement plus fragile que le code audité, et concluons sur ce que cela change pour les protocoles et les utilisateurs. Ce n'est pas un manuel sur la façon d'attaquer quoi que ce soit — c'est une lecture du schéma et de la défense.

Pourquoi le contrat intelligent n'est-il plus la cible ?

Pendant des années, l'image mentale du hack DeFi était celle de l'exploit de contrat : une faille de reentrancy, une manipulation d'oracle, une fonction de retrait mal protégée. L'attaquant lisait le code public, trouvait la faille mathématique et vidait le pool en un bloc. L'industrie a répondu avec la machine qui définit aujourd'hui un protocole sérieux : audits multiples, vérification formelle, bug bounties à sept chiffres (Aave paie jusqu'à 1 million de dollars sur Immunefi pour une faille critique) et bibliothèques standards révisées par des milliers d'yeux. Le contrat est devenu la partie la plus coûteuse à attaquer de tout le système.

Et c'est précisément pour cela qu'il a cessé d'être une cible rentable. La logique est celle de tout attaquant rationnel : on n'entre pas par la porte blindée quand la fenêtre de la salle de bain est ouverte. Un contrat audité est un code quasi immuable, public, scruté par des défenseurs qui ferment ce type précis de failles depuis des années. Le périmètre qui l'entoure — l'éditeur du développeur, le pipeline de déploiement, les nœuds RPC (les serveurs qui transmettent l'état de la chaîne aux applications) qui alimentent un pont, les agents de IA avec permissions de mouvement de fonds — ne bénéficie pas d'un dixième de cet examen. Il change quotidiennement, est maintenu par des personnes pressées et presque personne ne l'audite avec la rigueur appliquée à une fonction Solidity.

Les données le confirment. Selon TRM Labs, 76 % de toute la valeur volée en crypto en 2026 a été concentrée par le groupe Lazarus de Corée du Nord en seulement deux opérations. Aucune des deux n'était un exploit de logique de contrat : l'une a attaqué la configuration d'un pont, l'autre a consisté en des mois d'ingénierie sociale contre des opérateurs humains. Le gros argent de 2026 n'est pas passé par le code. Il est passé par tout le reste.

Quels sont les quatre vecteurs de périmètre de 2026 ?

La thèse ne repose pas sur un cas isolé, mais sur un modèle. Quatre incidents publics de 2026, chacun attaquant une couche différente du périmètre, dessinent le même déplacement. Dans aucun d'eux la logique du contrat n'a failli ; dans les quatre, c'est l'infrastructure environnante qui a échoué.

Il convient de lire ce tableau comme une carte, non comme une simple liste d'événements. Chaque ligne est une couche de la pile dont un protocole a besoin pour fonctionner mais qui n'apparaît pas dans son rapport d'audit. Le contrat est la seule pièce couverte par ces rapports — et c'est la seule qui a tenu dans les quatre cas.

Comment Kelp DAO est-il tombé sans qu'un contrat soit touché ?

Le 18 avril 2026, Kelp DAO a perdu 292 millions de dollars via son pont sur LayerZero. Il n'y a pas eu de bug Solidity. Le pont fonctionnait avec une configuration DVN (le réseau de vérificateurs qui approuve les messages entre chaînes) en mode « 1 sur 1 » : un vérificateur unique validait les messages cross-chain, sans redondance. L'attaquant a empoisonné les nœuds RPC que ce vérificateur consultait pour lire l'état de la chaîne d'origine et, parallèlement, a lancé un DDoS (saturation de trafic) contre cette infrastructure. Avec le vérificateur lisant un état manipulé, il a fabriqué un faux message ordonnant au pont de libérer 116 500 rsETH sur Ethereum sans qu'il y ait de burn correspondant à l'origine.

Le plus frappant dans ce cas est que l'avertissement existait. LayerZero avait signalé le risque de la configuration 1-sur-1 avant le hack ; environ 47 % des applications sur LayerZero utilisaient ce même défaut. Kelp gérait des milliards et n'a jamais renforcé sa sécurité au-delà de la configuration par défaut. Le contrat du pont faisait exactement ce pour quoi il était programmé — le problème venait de l'infrastructure qui décidait quels messages étaient légitimes. L'onde de choc a touché plus de vingt protocoles connectés et a déclenché plus de 10 milliards de dollars de sorties sur Aave, bien que les contrats d'Aave n'aient pas non plus été exploités : ils se sont simplement retrouvés avec du collatéral en litige. Nous l'analysons en détail dans comment ils ont volé 292 millions de Kelp DAO sans toucher à un contrat.

Pourquoi un agent de IA avec permissions est-il une bombe à retardement ?

Step Finance, un gestionnaire de portefeuilles DeFi sur Solana, a été vidé en janvier 2026 et a fini par fermer le 24 février. Le montant avoisine les 27 millions de dollars (261 854 SOL en une seule transaction ; certains rapports l'élèvent à 40 millions en comptant l'effondrement de 97 % de son token). Le vecteur initial était humain et classique : compromettre les appareils des cadres du projet pour s'emparer de leurs clés. Mais l'amplificateur était nouveau.

Step Finance avait intégré des agents de IA avec la permission d'exécuter des transferts importants de SOL sans approbation humaine. Une fois à l'intérieur, les attaquants n'ont pas eu à déplacer l'argent manuellement : ils ont utilisé les propres agents du protocole — avec leurs permissions excessives et sans isolation — comme levier pour extraire les fonds. La faille n'était ni le contrat ni le modèle de IA en soi, mais l'automatisation avec permissions : une identité machine capable de déplacer de la valeur sans humain dans la boucle transforme un compromis de références en un drainage instantané. C'est le même principe qui, en sécurité traditionnelle, rend dangereux un service avec des privilèges d'administrateur que personne ne révise.

Le cas voisin est Resolv USR (25 millions de dollars) : une injection de prompts dans un agent de IA avec accès au cloud, attaquant la couche d'outils — MCP, Supabase, clés gérées dans AWS KMS — au lieu du contrat. Deux incidents, deux points différents de la même nouvelle couche : l'infrastructure de IA que les protocoles connectent à leurs opérations plus vite qu'ils ne la sécurisent. Le détail de l'injection de prompts se trouve dans 25 millions volés par injection de prompts dans MCP.

Comment l'attaquant entre-t-il par la chaîne d'outils du dev ?

Le quatrième vecteur est le plus insidieux car il agit avant même que le contrat n'existe. Le 18 mai 2026, le groupe TeamPCP (identifié comme UNC6780) a publié une version empoisonnée de Nx Console, l'extension officielle de VS Code pour le monorepo Nx, comptant 2,2 millions d'installations. Elle est restée disponible sur le Marketplace officiel moins de 20 minutes — assez pour que la mise à jour automatique la pousse vers un nombre inconnu de machines. Le payload, baptisé Mini Shai-Hulud, volait des tokens de CI/CD, s'autopropageait comme un ver npm et balayait les chemins de wallets sur le disque. GitHub a confirmé l'exfiltration d'environ 3 800 de ses dépôts internes.

L'innovation effrayante n'a pas été de briser une défense, mais de la coopter : le ver générait des attestations de provenance SLSA Build Level 3 authentiques pour les paquets malveillants. En d'autres termes, la signature cryptographique que l'industrie a construite après SolarWinds pour certifier qu'un paquet provenait d'un pipeline fiable était correcte — sauf que le pipeline était déjà détourné. Pour un développeur Web3, c'est critique : sur sa machine cohabitent la clé qui signe un déploiement de contrat et la seed d'un wallet de trésorerie. Aucun département des fraudes ne peut annuler la transaction : si l'extension fait fuiter cette clé et que l'attaquant signe, les fonds sont partis. Ce qui est révélateur dans cet incident, c'est ce qui a limité les dégâts — selon GitHub, les dépôts des clients n'ont pas été affectés car l'accès compromis était ségrégué. La discipline des permissions, et non le contrat, a été la dernière ligne de défense.

Pourquoi le périmètre est-il plus fragile que le contrat ?

La question clé n'est pas de savoir pourquoi les attaquants se sont déplacés vers le périmètre, mais pourquoi le périmètre le permet. La réponse réside dans une asymétrie structurelle entre deux types de surfaces.

Le contrat intelligent possède quatre propriétés qui le renforcent : il est public (n'importe qui peut l'auditer), il est quasi immuable (il ne change pas après déploiement), il a un périmètre délimité (l'ensemble des fonctions est fini et connu) et il concentre toute l'attention défensive du secteur. L'infrastructure qui l'entoure est exactement l'inverse sur ces quatre points :

• Elle change quotidiennement. Un contrat est audité une fois et reste fixe. La toolchain du développeur, les nœuds RPC, les dépendances npm et la configuration des agents mutent constamment. Chaque mise à jour est une nouvelle fenêtre, et personne ne ré-audite l'ensemble du système à chaque changement.
• Elle est opaque et dispersée. Le code du contrat est sur un explorateur de blocs à la vue du monde entier. La configuration du DVN d'un pont, les permissions d'un agent de IA ou les tokens résidant dans un pipeline CI/CD ne sont ni publiés ni scrutés. Le défaut vulnérable de Kelp était là depuis des mois, signalé, sans que personne ne le change.
• Elle hérite de la confiance de tiers. Le protocole ne contrôle pas le VS Code Marketplace, ni le registre npm, ni les nœuds RPC d'un fournisseur, ni le pipeline cloud. Il leur fait confiance. TeamPCP n'a pas attaqué le contrat : il a attaqué le maillon de confiance — une extension signée — que le développeur considère comme sûr.
• Presque personne ne l'audite avec la même rigueur. Il existe des bug bounties d'un million de dollars pour une faille de contrat et une vérification formelle de chaque fonction. L'équivalent n'existe pas pour « votre pont est-il bien configuré ? » ou « que peut déplacer votre agent de IA sans humain devant lui ? ». Le budget sécurité a été dépensé sur la partie déjà solide.

La conséquence est directe : le coût marginal pour trouver une faille dans le périmètre est bien inférieur à celui nécessaire pour briser un contrat audité, et la récompense est identique — les mêmes fonds. Un attaquant rationnel, et Lazarus l'est, va là où le rapport effort-récompense est le meilleur. En 2026, c'est l'infrastructure.

Cela signifie-t-il que les exploits de contrat ont disparu ?

Non, et la nuance est importante pour ne pas tomber dans le titre facile. Les failles de logique de contrat — reentrancy, manipulation d'oracles, erreurs d'arrondi — continuent de se produire et continueront de se produire, surtout dans les protocoles jeunes, non audités ou avec du code copié à moitié. L'anatomie de ces failles n'a pas changé et il convient de la connaître ; nous la passons en revue dans l'anatomie d'une vulnérabilité crypto.

Ce que la thèse affirme est plus précis : le gros argent de 2026 s'est déplacé vers le périmètre. Sur les 606 millions volés en avril — 3,7 fois le total du premier trimestre complet —, deux attaques de Lazarus ont concentré près de 95 %, et aucune n'était un exploit de contrat. Quand le code est devenu si robuste que vider un protocole sérieux par la voie mathématique est hors de prix, les grands opérateurs migrent vers la voie bon marché. Les exploits de contrat ne sont pas morts ; ils ont été relégués aux proies faciles, tandis que les grosses proies tombent par le périmètre. C'est une redistribution du risque, pas une substitution.

Qu'est-ce que cela change pour les protocoles ?

Si l'attaque n'entre plus par le contrat, auditer seulement le contrat revient à défendre une porte blindée avec la fenêtre ouverte. La défense se déplace avec l'attaque. Pour un protocole, cela implique de traiter le périmètre avec la même rigueur que le code :

1. Auditer la configuration, pas seulement le code. Le défaut d'un pont, le mode du DVN, les fournisseurs RPC et leur redondance font partie de la surface d'attaque. Kelp avait un contrat correct mais un pont en « 1 sur 1 » : l'audit qui importait était celui de la configuration, et il n'a pas été fait.
2. Permissions minimales pour les agents de IA. Aucune identité machine ne devrait pouvoir déplacer de la valeur sans un humain dans la boucle ou sans limites strictes. Un agent avec permission de transfert illimitée est, en pratique, une clé privée dotée d'une volonté propre. La leçon de Step Finance est exactement celle-là.
3. Ségréguer les références par rayon d'explosion. Le token qui construit ne doit pas être celui qui publie ; la clé qui teste ne doit pas être celle qui déploie en production. Dans le cas TeamPCP, les dépôts clients de GitHub ont été sauvés précisément parce que l'accès compromis ne les atteignait pas : la ségrégation a contenu les dégâts.
4. Renforcer la toolchain du développeur. Mises à jour manuelles et révisées sur les machines manipulant des clés, scepticisme face à la provenance signée (qui ne suffit plus comme garantie), et ne jamais laisser de seeds de production à portée de la session d'un éditeur.
5. Ne pas ignorer les avertissements déjà reçus. LayerZero avait prévenu Kelp. Le défaut vulnérable était documenté. La défense du périmètre commence par agir sur le risque connu avant de chercher l'inconnu.

La différence de fond sur l'identité de celui qui exécute l'attaque est traitée à part : si vous vous demandez si l'IA est déjà l'attaquant autonome qui vide les protocoles, la réponse et les données sont dans l'alarme d'OpenZeppelin sur l'IA « superhumaine ». Cet article traite de qui attaque ; celui-ci, de quelle partie est attaquée. Ils sont complémentaires : au 1er juin 2026, l'attaquant reste humain et la cible s'est déplacée vers le périmètre.

Quels signaux un utilisateur devrait-il surveiller ?

L'utilisateur DeFi n'audite pas les ponts et ne configure pas les agents, mais son exposition dépend de décisions de périmètre qu'il peut évaluer avant de déposer. Quatre signaux pratiques :

• Risque de pont hérité. Tout token « wrapped » ou bridgé hérite du risque de l'infrastructure du pont, non du contrat qui l'émet. Si vous détenez des actifs cross-chain, il convient de savoir quel pont les soutient et dans quelle configuration. Pour comparer les architectures de vérification des grands ponts avant de déplacer des fonds, le comparateur de LayerZero, Wormhole et Axelar aide à voir les différences d'un coup d'œil.
• Concentration sur un seul fournisseur. Avoir toute son exposition cross-chain sous un unique fournisseur de pont revient à répliquer le point de défaillance unique qui a coulé Kelp. Diversifier réduit le rayon d'explosion également pour l'utilisateur.
• Collatéral avec support en litige. Si vous utilisez un actif bridgé comme collatéral en lending, votre position dépend de la validité continue de ce support. Lorsque le pont qui l'émet subit un incident, le Health Factor peut se détériorer sans que vous ne fassiez rien.
• Maturité du périmètre, pas seulement des audits. Un sceau d'audit couvre le contrat. Demander si le protocole publie sa configuration de ponts, comment il gère les permissions de ses automatisations et comment il ségrégue les références en dit plus sur son risque réel en 2026 que le nombre d'audits du contrat.

La leçon transversale est inconfortable mais claire : en 2026, lire seulement le rapport d'audit du contrat, c'est lire la partie qui est déjà résolue. Le risque vit dans la marge non auditée. Le contrat est examiné une fois et est public ; le périmètre change chaque jour et presque personne ne le surveille — et c'est là que, coup après coup, le gros argent tombe. Surveiller vos positions et la santé de votre portefeuille sert précisément à détecter tôt quand un incident de périmètre commence à contaminer les actifs que vous touchez.

Sources et liens : TRM Labs (attribution et % volé 2026) · BeInCrypto (606 M$ en avril, 3,7x Q1) · CoinDesk (fermeture de Step Finance) · Halborn (analyse Step Finance) · CISA (alerte TeamPCP / Nx Console) · Chainalysis (attribution Lazarus)