Pourquoi les ponts crypto sont de nouveau piratés en 2026 : clés de validateurs, messages falsifiés et tokens wrapped non garantis

Les ponts inter-chaînes répondent à un problème fondamental de l’écosystème crypto : les actifs et les informations créés sur une blockchain ne peuvent généralement pas être transférés directement vers une autre. Un pont établit cette connexion en verrouillant, libérant, créant ou détruisant des actifs en fonction des messages reçus d’un autre réseau. Cette commodité crée toutefois un risque de sécurité important. Un attaquant n’a pas toujours besoin de compromettre Ethereum, Arbitrum, une chaîne Cosmos ou une autre blockchain sous-jacente. Il peut lui suffire de prendre le contrôle du système plus restreint qui indique au pont ce qui s’est produit ailleurs. Les incidents recensés en 2026 montrent que le point faible peut être une clé de validateur, un service hors chaîne chargé de préparer les messages, un composant de vérification des preuves ou un contrat qui crée des tokens wrapped. Le résultat est souvent identique : le pont accepte un événement qui n’aurait jamais dû être autorisé et libère des actifs réels en contrepartie. Les cas récents impliquant AFX Trade, Alephium, Hyperbridge et la connexion d’Axelar à Secret Network montrent pourquoi la sécurité des ponts dépend autant des contrôles opérationnels et de la validation des messages que du code des smart contracts.

Pourquoi les ponts inter-chaînes restent une cible de grande valeur en 2026

Un pont se situe en pratique entre plusieurs systèmes comptables indépendants. Lorsqu’un utilisateur transfère un actif de la chaîne A vers la chaîne B, l’actif d’origine peut être verrouillé dans un contrat sur la chaîne A tandis qu’une représentation correspondante est émise sur la chaîne B. Lorsque l’utilisateur revient sur la chaîne d’origine, la version wrapped est détruite et l’actif initial est libéré. D’autres architectures utilisent des pools de liquidité, une émission native ou des systèmes spécialisés de messagerie, mais toutes doivent répondre à la même question : comment une blockchain peut-elle accepter de manière sûre une information concernant un événement survenu sur un autre réseau ? Les blockchains savent vérifier leur propre état. Elles ne savent pas automatiquement si un dépôt, une destruction de tokens ou un retrait a réellement eu lieu sur une autre chaîne.

Cette caractéristique rend les ponts particulièrement attractifs pour les attaquants, car une seule faille peut donner accès à des réserves mutualisées plutôt qu’au portefeuille d’un utilisateur isolé. Un pont peut conserver des stablecoins, de l’Ether, des actifs adossés au Bitcoin et d’autres tokens pour le compte de milliers d’utilisateurs. La valeur concentrée dans ces contrats de dépôt peut donc devenir bien supérieure à la valeur économique protégeant un validateur, un serveur ou une clé administrative individuelle. Même lorsque les smart contracts ont été audités, un attaquant peut rechercher des vulnérabilités en dehors du contrat lui-même : infrastructure des validateurs, systèmes de déploiement, connexions RPC, relayeurs, autorisations de mise à niveau, comptes cloud ou logiciels utilisés pour construire les messages inter-chaînes.

Ce schéma est resté visible tout au long de l’année 2026. Le 22 juillet, le pont exploité par AFX Trade a perdu environ 24,15 millions de dollars en USDC après la compromission d’un nombre suffisant de clés de signature de validateurs pour atteindre le seuil requis pour un retrait. Le 27 août, SKALE a indiqué que des prestataires d’infrastructure exploitant des nœuds validateurs avaient été compromis avant une attaque contre son IMA Bridge côté Ethereum. Ces incidents n’ont pas nécessité de contourner le mécanisme de consensus des blockchains sous-jacentes. Ils ont ciblé les systèmes de confiance plus restreints placés entre les chaînes, où le contrôle d’un nombre limité de machines ou d’identifiants pouvait être transformé en autorité sur des réserves beaucoup plus importantes.

Le problème de confiance derrière les transferts inter-chaînes

Le terme « pont » peut donner l’impression que les transferts inter-chaînes correspondent à un déplacement classique d’un réseau vers un autre, mais les actifs ne passent généralement pas d’une blockchain à l’autre au sens littéral. Un système prouve ou atteste plutôt qu’un événement a eu lieu sur la chaîne source, puis un autre système modifie les soldes de la chaîne de destination en conséquence. Selon l’architecture utilisée, cette preuve peut provenir d’un groupe de validateurs, d’un ensemble de guardians, d’un mécanisme de client léger, d’une preuve cryptographique ou d’un autre processus de vérification. Les utilisateurs dépendent donc non seulement de la sécurité des deux blockchains, mais aussi de l’intégrité du mécanisme qui les relie.

Cette distinction est importante, car une transaction peut être cryptographiquement valide tout en étant frauduleuse sur le plan économique. Supposons qu’un pont exige cinq signatures approuvées avant de libérer des USDC. Si un attaquant obtient cinq clés de signature légitimes, le retrait final peut contenir des signatures parfaitement valides. Le contrat ne dispose d’aucun moyen indépendant pour comprendre que ces signatures ont été produites par un attaquant. De son point de vue, les validateurs requis ont approuvé la demande. La cryptographie fonctionne exactement comme prévu, mais l’hypothèse de sécurité sur laquelle reposent les signatures a déjà été compromise.

Un problème comparable apparaît lorsque des signataires légitimes reçoivent des informations incorrectes. Les validateurs peuvent signer honnêtement un message parce que l’infrastructure qui leur fournit les données signale un dépôt ou une destruction de tokens qui n’a jamais eu lieu. C’est l’une des raisons pour lesquelles la sécurité d’un pont ne peut pas se résumer à la question de savoir si des clés privées ont été volées. Les développeurs doivent également examiner l’origine des données reçues par les validateurs, vérifier si plusieurs sources indépendantes confirment le même événement, identifier les messages inhabituels et définir la réaction du système lorsqu’un retrait exceptionnellement important apparaît soudainement. La fiabilité du pont dépend de l’ensemble du parcours allant de l’événement initial sur la blockchain jusqu’à la libération finale des fonds.

Clés de validateurs et messages falsifiés : comment les attaques contournent les contrôles habituels

Les clés de validateurs deviennent particulièrement dangereuses lorsque plusieurs d’entre elles sont stockées dans des environnements similaires ou contrôlées par une même organisation. Une architecture reposant sur un seuil de signatures peut sembler décentralisée parce qu’elle exige cinq, sept ou dix signatures, mais sa protection réelle dépend de la capacité de ces identifiants à subir des défaillances indépendantes. Si plusieurs clés sont hébergées sur des serveurs actifs comparables, utilisent les mêmes outils d’administration ou sont accessibles depuis un même réseau interne, la compromission d’un seul environnement opérationnel peut permettre à un attaquant d’obtenir suffisamment de signatures pour atteindre le quorum requis. Le nombre de clés perd de son importance lorsqu’elles sont toutes exposées au même vecteur d’attaque.

L’incident d’AFX Trade en juillet 2026 illustre clairement ce problème. Les analyses de sécurité consacrées à l’incident ont montré que cinq signatures de validateurs actifs étaient suffisantes pour autoriser un retrait d’environ 24,15 millions d’USDC. Le contrat du pont a reconnu le quorum requis et exécuté la demande après l’expiration de sa période de contestation. Le pont natif d’Arbitrum n’était pas le composant défaillant ; le pont concerné était exploité par AFX. Cette distinction est importante, car les utilisateurs voient souvent des actifs circuler entre deux chaînes connues et supposent que la sécurité du transfert découle directement de celle de ces réseaux. En réalité, un pont distinct peut introduire son propre ensemble de validateurs, ses propres mécanismes de conservation et ses propres faiblesses administratives.

Le vol de clés n’est qu’un moyen parmi d’autres de produire un message qui semble valide. Un pont peut également être amené à accepter de fausses informations sans qu’aucune clé privée de signataire ne soit volée. Un attaquant peut manipuler les données transmises aux validateurs, exploiter une erreur de vérification, créer une preuve qu’un contrat accepte à tort ou profiter d’une différence d’interprétation entre deux logiciels concernant une même transaction. Ces attaques sont particulièrement difficiles à diagnostiquer rapidement, car le message final peut contenir de véritables signatures ou passer avec succès les fonctions de vérification attendues. Les enquêteurs doivent alors remonter toute la chaîne, depuis les relayeurs et les données RPC jusqu’à la génération des preuves et à la construction des messages, afin de déterminer à quel moment le faux état a été introduit.

Ce que révèlent les incidents de 2026

L’incident du pont Alephium du 30 mai 2026 constitue un exemple instructif, car les premières apparences auraient pu orienter les enquêteurs vers un vol des identifiants des guardians. Alephium a ensuite indiqué que les clés des guardians n’avaient pas été compromises. Selon son rapport d’incident, l’attaquant a combiné l’absence d’une vérification dans un processus hors chaîne de réobservation avec une attaque de type eclipse visant les nœuds complets du pont. Des guardians légitimes ont ainsi signé des messages qui étaient cryptographiquement authentiques, mais qui n’auraient jamais dû être autorisés. Environ 305 000 dollars de garanties ont été retirés des contrats TokenBridge sur Ethereum et BNB Chain, tandis qu’environ 13,76 millions de wALPH non garantis ont été créés sur Ethereum.

Hyperbridge a subi une défaillance de vérification différente le 13 avril 2026. Son rapport d’incident indique qu’un attaquant a exploité une faille critique dans le vérificateur Merkle Mountain Range et créé une preuve falsifiée que le système a acceptée. L’attaquant a ensuite pu vider le contrat Token Gateway. Cette attaque ne reposait pas sur le vol d’un nombre suffisant de clés de validateurs. Le composant chargé de déterminer si une preuve inter-chaînes était valide a simplement fourni une réponse incorrecte. Hyperbridge a suspendu la passerelle concernée et a ensuite commandé un audit indépendant de ses mécanismes de vérification et de règlement, ce qui montre pourquoi l’examen de la sécurité d’un pont doit aller au-delà des contrats de tokens les plus visibles.

Ces cas montrent pourquoi l’expression « message falsifié » peut désigner des défaillances très différentes. Une attaque peut reposer sur des clés volées qui signent réellement un retrait malveillant. Une autre peut transmettre de fausses données à des signataires honnêtes. Une troisième peut exploiter un vérificateur afin que des preuves fabriquées soient acceptées sans aucune compromission des validateurs. Du point de vue de l’utilisateur, les trois scénarios peuvent se terminer par la disparition des actifs conservés dans un contrat de réserve. Du point de vue de la sécurité, ils nécessitent toutefois des défenses différentes. La protection matérielle des clés ne peut pas corriger un vérificateur de preuves défectueux, tandis qu’un vérificateur irréprochable ne protège pas un système dont les identifiants d’administrateur ou de validateur ont été volés. Une sécurité efficace des ponts nécessite donc plusieurs contrôles indépendants plutôt qu’un seul point de confiance.

Tokens wrapped non garantis et problème de liquidité

Les tokens wrapped ajoutent une couche de risque supplémentaire, car leur valeur sur le marché dépend de l’hypothèse selon laquelle ils peuvent finalement être échangés contre un actif réel. Si un ETH wrapped représente une créance sur un ETH détenu ailleurs, le système reste équilibré uniquement tant que la quantité émise correspond aux actifs qui la garantissent. Lorsqu’une vulnérabilité du pont permet à un attaquant de créer des tokens wrapped supplémentaires sans déposer les garanties correspondantes, ces nouveaux tokens peuvent initialement sembler identiques aux unités légitimement garanties. Ils peuvent être transférés, échangés ou déposés dans d’autres services DeFi avant que le marché ne réalise que le volume total des créances dépasse désormais les réserves disponibles.

L’incident de juin 2026 concernant la connexion d’Axelar à Secret Network fournit un exemple concret. L’analyse de sécurité a montré qu’un contrat de pont modifié acceptait des dépôts IBC sans vérifier correctement le canal source attendu. Un attaquant pouvait créer une chaîne distincte basée sur Cosmos, envoyer des paquets de dépôt spécialement conçus et provoquer l’émission d’actifs wrapped sur Secret Network sans les dépôts légitimes correspondants. Ces actifs non garantis étaient ensuite acheminés via la connexion valide d’Axelar puis échangés contre de véritables tokens conservés en garantie. Environ 4,67 millions de dollars ont été dérobés, et le déficit n’a pas été identifié immédiatement ; les analyses de l’incident indiquent que le problème est devenu apparent plusieurs jours plus tard lorsqu’un transfert inter-chaînes normal n’a plus pu être finalisé en raison de réserves insuffisantes.

Ce type d’attaque est particulièrement dommageable parce qu’il peut dépasser le cadre du pont lui-même. Lorsqu’un actif wrapped non garanti entre dans un échange décentralisé, un marché de prêt ou un pool de liquidité, d’autres utilisateurs peuvent, sans le savoir, échanger des actifs réels contre des créances qui ne sont plus entièrement couvertes. Les contrats automatisés ne savent généralement pas pourquoi des tokens supplémentaires ont été créés. Ils se contentent de lire les soldes et d’appliquer les règles prévues par leur code. Une faille de sécurité sur un seul pont peut donc transférer les pertes vers des fournisseurs de liquidité, des traders ou des services DeFi connectés. Lorsque le pont concerné est finalement suspendu, l’attaquant peut déjà avoir converti les fausses créances en stablecoins ou en d’autres actifs largement négociés.

Comment une conception plus sûre des ponts peut limiter les dégâts

La première ligne de défense consiste à réduire le niveau d’autorité qu’un identifiant ou qu’un système individuel peut exercer. Les clés de validateurs devraient être réparties entre des environnements réellement indépendants plutôt que simplement représentées par des adresses différentes. Les mises à niveau administratives peuvent être protégées par des approbations multisignatures, des délais d’exécution et des autorisations strictement limitées. Les retraits importants ou inhabituels peuvent être soumis à des périodes de contestation plus longues, tandis que des limites de débit peuvent restreindre la quantité de valeur pouvant quitter un pont sur une courte période. Aucun de ces contrôles ne garantit qu’une attaque sera empêchée, mais ils peuvent éviter qu’un compte compromis ou qu’un message inattendu ne vide immédiatement l’ensemble des réserves.

La vérification des messages doit également comporter plusieurs contrôles indépendants. Un pont doit confirmer la chaîne source, le contrat, l’actif, le montant, la destination et l’ordre du message plutôt que de considérer qu’une signature valide prouve automatiquement que tous les champs sont corrects. Les systèmes reposant sur des observateurs hors chaîne doivent tenir compte du scénario dans lequel ces observateurs reçoivent des réponses RPC manipulées ou perdent une vision exacte de la chaîne source. L’offre de tokens wrapped devrait être comparée en permanence aux réserves correspondantes afin qu’une hausse inexpliquée puisse déclencher une alerte ou une suspension automatique. La surveillance est particulièrement utile lorsqu’elle vérifie des invariants économiques, par exemple si les créances émises correspondent toujours aux garanties disponibles, au lieu de rechercher uniquement des transactions ayant échoué.

La principale leçon de 2026 est que les attaques contre les ponts ne peuvent plus être expliquées correctement en affirmant simplement que « le smart contract a été piraté ». Dans plusieurs incidents importants, la faiblesse décisive se trouvait ailleurs : identifiants de validateurs, infrastructure fournissant des données aux guardians, validation du canal source ou vérification des preuves. Une architecture sûre doit donc partir du principe que certains composants peuvent tomber en panne et empêcher qu’une seule défaillance devienne un droit illimité sur les réserves du pont. Les utilisateurs qui évaluent un pont devraient regarder au-delà de la vitesse des transactions et du nombre de chaînes prises en charge, et examiner qui contrôle les signataires, comment les messages sont vérifiés, si les actifs wrapped peuvent être comparés indépendamment aux réserves, à quelle vitesse une activité anormale peut être interrompue et quel processus de récupération existe lorsque ces contrôles échouent.