Le réseau Secret perd 4,67 millions de dollars dans un exploit inter-chaînes Axelar — Indétecté pendant sept jours
Le réseau Secret perd 4,67 millions de dollars dans un exploit inter-chaînes Axelar — Indétecté pendant sept jours
Le 21 juin 2026, des chercheurs de Common Prefix ont publié leurs découvertes sur un incident de pont inter-chaînes impliquant le réseau Secret et un contrat connecté à Axelar. L'attaquant aurait exploité une faille dans un contrat de pont ICS-20 côté Secret, forgé des « dépôts », minté des tokens non gagés et retiré des liquidités pour un montant estimé à 4,67 millions de dollars.
Ce qui rend cet événement particulièrement instructif, ce n'est pas seulement le montant de la perte — c'est la chronologie : l'exploit aurait persisté pendant environ une semaine avant que quiconque ne s'en aperçoive, et le premier signal concret n'a pas été une alerte, mais une défaillance opérationnelle lorsqu'un transfert légitime n'a pas pu être effectué.
Cet article détaille ce qui s'est passé, pourquoi le mode de défaillance est courant dans les systèmes inter-chaînes, et ce que les utilisateurs comme les développeurs peuvent faire pour réduire leur exposition à mesure que l'interopérabilité devient la norme dans la conception des produits crypto en 2025-2026.
Ce qui se serait passé : une chronologie claire, une alarme retardée
Sur la base de l'enquête divulguée :
- 10 juin 2026 : l'attaquant a commencé à abuser d'une vulnérabilité dans un contrat de pont inter-chaînes Secret Network ↔ Axelar en falsifiant l'état des transferts entrants et en mintant des tokens sans garantie.
- 10-17 juin 2026 : l'attaquant a converti à plusieurs reprises les actifs mintés en tokens plus liquides et a acheminé les produits dehors.
- 17 juin 2026 : un transfert inter-chaînes normal a échoué car le compte de garde/dépôt du pont ne disposait plus de fonds suffisants — mettant en évidence l'anomalie.
Ce schéma de « drain silencieux jusqu'à ce qu'un utilisateur se heurte à un mur » est un risque opérationnel récurrent pour les ponts : si la surveillance se concentre sur la disponibilité et le débit des messages (plutôt que sur les invariants économiques), les exploits peuvent se cacher à la vue de tous.
Pour les lecteurs qui souhaitent un rappel sur la manière dont les transferts de tokens de type IBC sont généralement modélisés (dépôt d'un côté, représentation mintée de l'autre), la documentation du réseau Secret sur les outils liés à IBC et ICS-20 est un bon point de départ.
Cause profonde (telle que décrite) : quand un modèle de dépôt devient un modèle de minting
L'analyse divulguée attribue le bug principal à un refactoring de contrat : un passage d'un flux de garde / dépôt à un flux de minting — tout en supprimant des vérifications critiques qui prouvaient l'origine du transfert.
En langage simple :
- Un contrat de pont reçoit un message inter-chaînes affirmant : « X tokens ont été déposés sur la chaîne A pour l'utilisateur Y ».
- Le contrat de destination doit vérifier que le message provient bien du canal / passerelle / expéditeur attendu.
- Ce n'est qu'alors qu'il doit mint ou libérer des actifs.
Selon la divulgation, le contrat vulnérable a supprimé deux fonctions clés responsables de la validation de la source des transferts, permettant à un attaquant de soumettre des données qui ressemblaient à un transfert entrant valide et de déclencher un minting sans garantie réelle.
Pire encore, le rapport indique que le contrat avait été déployé depuis début 2023 et n'avait jamais fait l'objet d'un audit externe — une lacune en matière de gouvernance et de processus difficile à justifier pour tout contrat contrôlant une autorité de minting inter-chaînes.
Pour avoir une idée de l'importance attendue des audits de ponts au niveau de l'infrastructure, vous pouvez consulter les ressources d'audit publiques d'Axelar dans le dépôt d'audits d'Axelar Network et la perspective d'Axelar dans son article sur la sécurité au cœur d'Axelar.
Pourquoi cela n'a pas été remarqué : « pas de sirènes » avant que le coffre ne soit vide
Une affirmation clé du réseau Secret est que l'infrastructure de pont d'Axelar n'a pas déclenché de détection d'anomalie efficace ni de mécanisme de pause d'urgence avant que des fonds significatifs n'aient déjà quitté le système.
Que la responsabilité incombe finalement au contrat d'application, au fournisseur de pont, ou aux opérations partagées, la leçon est plus large :
Les systèmes inter-chaînes ont besoin d'une surveillance économique, pas seulement technique
Les ponts ne sont pas seulement des « tuyaux de messages ». Ce sont des systèmes financiers avec des invariants :
- Offre mintée vs. garantie déposée
- Limites de minting quotidiennes
- Plafonds d'exposition par route
- Schémas de rachat / échange anormaux
- Pic de transferts échoués (souvent un symptôme tardif)
En 2026, l'industrie réévalue déjà ce risque. Par exemple, après un incident distinct lié à un pont, Aave a décidé de renforcer ses normes de cotation et de gestion des risques — soulignant comment la fragilité des ponts peut se répercuter sur les marchés monétaires de la DeFi (couverture CoinDesk).
Où sont allés les fonds : routage Osmosis, règlement Ethereum, puis sorties vers les CEX
Le traçage divulgué indique un parcours de blanchiment familier :
- Les actifs ont été acheminés via les canaux de liquidité Cosmos, apparemment via Osmosis, qui fonctionne comme un important hub DEX inter-chaînes (voir la documentation Osmosis).
- Les produits ont ensuite été transférés vers Ethereum et échangés contre de l'ETH en utilisant CoW Protocol (voir la documentation CoW Protocol), avant d'être fragmentés sur plusieurs adresses.
- Certains fonds auraient atteint des plateformes centralisées, notamment KuCoin, ChangeNow et HitBTC.
Le rapport affirme également qu'environ 672 000 $ restaient dans un portefeuille Axelar contrôlé par l'attaquant au moment de la publication, et que les demandes de gel de cette adresse ont été refusées — tandis qu'Axelar a souligné que le contrat exploité n'avait pas été développé ni maintenu par Axelar, et que le protocole central d'Axelar n'avait pas été compromis.
Ce que cet incident révèle sur le risque des ponts en 2025-2026
L'interopérabilité s'accélère — l'expérience utilisateur des portefeuilles tend vers le « inter-chaînes en un clic », et les applications supposent de plus en plus l'abstraction de chaîne par défaut. Mais cette commodité élargit la surface d'attaque de trois manières :
- Plus de contrats obtiennent des autorisations de minting quelque part (et l'autorisation de minting est le privilège le plus élevé dans la conception de tokens).
- Les refactorisations sont fréquentes car les équipes recherchent des routes plus rapides, des frais plus bas et une meilleure UX — introduisant souvent des risques de régression.
- La responsabilité devient ambiguë entre les équipes d'application, les fournisseurs de ponts, les relais et les piles de surveillance.
Le résultat : même si un réseau de pont est robuste, un seul contrat d'intégration faible peut devenir le point de défaillance.
Points à retenir pratiques
Pour les développeurs : réduire le « rayon d'explosion de l'autorité de minting »
- Traitez tout contrat de minting inter-chaînes comme un composant systématiquement important : audits externes obligatoires, portes d'examen formelles et surveillance continue.
- Ajoutez des disjoncteurs : limites de débit, plafonds par actif et déclencheurs de pause automatiques liés aux violations d'invariants.
- Surveillez le ratio garantie vs. offre mintée sur chaque route ; alertez sur la dérive, pas seulement sur les pannes.
- Évitez de supprimer la logique de validation lors des « changements de modèle » (dépôt → mint, ou inversement) sans examen contradictoire et tests de régression.
Pour les utilisateurs : considérez les ponts comme plus risqués que les échanges spot
- Ne conservez que ce dont vous avez besoin sous forme représentée par les ponts ; ne considérez pas les actifs enveloppés comme un stockage froid à long terme.
- Après avoir utilisé un pont, envisagez de transférer vos fonds vers une auto-garde et de vérifier l'actif que vous avez reçu (chaîne, dénomination, contrat) avant d'interagir davantage.
- Privilégiez les flux de travail où vous pouvez vérifier indépendamment ce que vous signez et où cela va — en particulier lorsque vous pontifiez et échangez sur plusieurs sauts.
L'endroit où OneKey s'insère : l'auto-garde dans un monde inter-chaînes
Les incidents de ponts nous rappellent que « pas vos clés, pas vos coins » n'est que la moitié de l'histoire — l'autre moitié est de minimiser le temps et la valeur que vous laissez dans des routes de smart contracts complexes.
Un portefeuille matériel comme OneKey vous aide en gardant vos clés privées hors ligne et en facilitant la révision et la confirmation des adresses de destination et de l'intention de la transaction avant de signer — une habitude importante lorsque l'UX inter-chaînes peut masquer ce qui se passe en coulisses.
Dans la réalité multi-chaînes de 2026, la règle par défaut la plus sûre est : utilisez un pont uniquement lorsque c'est nécessaire, vérifiez chaque signature, et revenez à l'auto-garde une fois terminé.
