Le bug de ZetaChain signalé par un chevalier blanc, qualifié de « prévu », et ayant conduit à une exploitation de 334 000 $
Le bug de ZetaChain signalé par un chevalier blanc, qualifié de « prévu », et ayant conduit à une exploitation de 334 000 $
Fin avril 2026, l'infrastructure inter-chaînes a une fois de plus prouvé comment de petites hypothèses de conception peuvent générer des risques disproportionnés. ZetaChain a confirmé qu'un attaquant avait siphonné environ 334 000 $ à partir de portefeuilles contrôlés par le protocole, via un enchaînement de faiblesses couvrant l'initiation des messages, les règles d'exécution sur la chaîne de destination et des autorisations ERC-20 de longue date. Les fonds des utilisateurs n'ont pas été affectés, mais l'incident reste un rappel cinglant : dans les systèmes inter-chaînes, les composants « à faible risque » restent rarement à faible risque lorsqu'ils interagissent.
Ce qui rend ce cas particulièrement instructif, c'est l'échec du processus derrière l'échec technique. ZetaChain a reconnu que le problème principal avait été signalé plus tôt via son canal de prime aux chasseurs de bugs, mais a été initialement traité comme un comportement attendu plutôt que comme quelque chose nécessitant une atténuation ou des contraintes plus strictes. La couverture de la divulgation et des détails post-incident se trouve dans des reportages tels que le résumé de Cointelegraph sur le rapport rejeté et l'exploitation ultérieure : ZetaChain a rejeté un rapport de bug qui aurait pu empêcher l'exploitation.
Voici une ventilation conviviale pour les opérateurs de ce qui s'est passé, pourquoi le chemin d'exploitation a fonctionné, ce que ZetaChain a modifié et ce que les développeurs et les utilisateurs devraient retenir en 2026, alors que l'activité inter-chaînes est plus étendue que jamais et que les tactiques des attaquants sont de plus en plus « multi-vecteurs par défaut ».
Instantané de l'incident : la dette de conception inter-chaînes se paye
Les actions de l'attaquant ont finalement entraîné 9 transactions couvrant Ethereum, Arbitrum, Base et BNB Smart Chain, les actifs volés provenant de portefeuilles contrôlés par ZetaChain plutôt que d'utilisateurs finaux. ZetaChain a mis en pause les opérations inter-chaînes le temps que le problème soit contenu ; l'arrêt initial a été largement rapporté lorsque l'incident a été rendu public pour la première fois (voir : le rapport de The Block sur la pause et l'atténuation).
Bien que le montant en dollars n'ait pas atteint l'ampleur d'un « méga-hack de pont », le modèle est ce qui importe : une passerelle inter-chaînes qui peut être influencée pour produire des appels signés par le protocole sur des chaînes externes est une cible à fort effet de levier, même lorsque l'ensemble des victimes immédiates est limité.
La leçon inconfortable : un « comportement attendu » peut toujours être un comportement exploitable
Les programmes de prime aux chasseurs de bugs sont destinés à convertir la curiosité des adversaires en améliorations défensives, mais seulement si le triage est conçu pour reconnaître le risque de composition.
ZetaChain a déjà lancé son programme de primes en partenariat avec Immunefi (contexte : Annonce du programme de primes aux chasseurs de bugs de ZetaChain). Pourtant, cet incident met en évidence un défi récurrent dans l'industrie : un rapport peut être « correct » même si chaque composant individuel semble non critique isolé. Immunefi lui-même souligne que l'impact réel et les définitions de portée sont importants (voir : Guide d'Immunefi sur les règles du programme et l'impact).
Pour les protocoles inter-chaînes, la barre devrait être plus élevée : si une fonctionnalité permet n'importe quel chemin vers « le protocole peut être trompé pour signer quelque chose qu'il ne devrait pas », alors elle mérite une défense en profondeur, même si la fonctionnalité fonctionne techniquement comme prévu.
Comment trois « petits » problèmes se sont enchaînés en une grande exploitation
Une analyse technique détaillée du flux d'appels et du comportement du contrat a été publiée par des chercheurs indépendants ; l'une des analyses étape par étape les plus claires est : Analyse du hack de ZebraChain Gateway.
Du point de vue de la conception de la sécurité, la chaîne d'exploitation peut être résumée en trois maillons :
1) Initiation d'instructions inter-chaînes sans permission au niveau de la passerelle
Un problème central était qu'un chemin côté passerelle pouvait être invoqué de manière à permettre à un attaquant d'injecter une intention inter-chaînes (c'est-à-dire « envoyer ce message/appel à la chaîne de destination ») sans que le système n'applique la limite de confiance attendue quant à qui est autorisé à déclencher de telles instructions.
Dans les systèmes inter-chaînes, qui est autorisé à émettre un signal « ceci doit être exécuté à distance » est la première et la plus importante ligne de défense.
2) Règles d'exécution de destination trop permissives (et trop dépendantes d'une liste restrictive étroite)
Du côté de la réception, le chemin d'exécution permettait des appels qui étaient effectivement de nature « arbitraire », avec des restrictions qui n'étaient pas suffisamment larges pour bloquer les opérations dangereuses sur les jetons. Une liste noire qui ne bloque que quelques sélecteurs est rarement suffisante lorsque la surface d'attaque de l'EVM est énorme, et lorsque les attaquants n'ont besoin que d'un seul primitif autorisé (comme transferFrom) pour monétiser.
C'est un mode de défaillance courant : les listes noires vieillissent mal dans les environnements hostiles.
3) Les autorisations ERC-20 obsolètes ont transformé « l'exécution » en « mouvement d'actifs »
Le dernier maillon était opérationnel plutôt que purement lié au code : certains portefeuilles maintenaient des approbations illimitées (ou des allocations autrement excessives) au contrat de passerelle et ne les supprimaient pas après qu'elles n'étaient plus nécessaires.
Dans ERC-20, une allocation est effectivement une permission permanente. Une fois qu'un contrat obtient la capacité d'effectuer un appel de jeton en son nom propre, toute allocation restante devient une arme chargée. Pour plus de contexte sur le fonctionnement des allocations au niveau standard, voir : Documentation ERC-20 d'OpenZeppelin.
La recherche a également montré à quel point les approbations illimitées sont répandues, et pourquoi elles créent un risque systémique, bien au-delà de tout protocole unique (voir : étude sur le risque d'approbation « Prudent à la livre et idiot à la livre »).
Artisanat de l'attaquant : pas opportuniste, mais orchestré
ZetaChain a décrit l'exploit comme présentant des signes clairs de planification, notamment :
- Pré-financement via Tornado Cash des jours à l'avance
- Déploiement d'un contrat de « drainer » dédié
- Campagne d'empoisonnement d'adresses
L'empoisonnement d'adresses mérite une attention particulière car il est de plus en plus intégré dans des opérations d'exploitation plus larges, non seulement comme une arnaque pour les particuliers, mais aussi comme un moyen de créer de la confusion lors de la réponse à incident. Si vous souhaitez un aperçu rigoureux de la technique et de la raison pour laquelle elle fonctionne si souvent, les chercheurs de Carnegie Mellon maintiennent une ressource dédiée ici : Aperçu de l'empoisonnement d'adresses blockchain.
Ce que ZetaChain a modifié : suppression des « pistolets de pied », pas seulement correction des bugs
Les correctifs post-incident sont plus importants lorsqu'ils réduisent le risque de classe plutôt que de simplement bloquer une charge utile observée. Sur la base de la direction de remédiation divulguée par ZetaChain (telle que résumée dans les rapports publics et les analyses techniques), les principaux changements comprennent :
- Déploiement de correctifs sur l'infrastructure du réseau principal pour fermer le chemin d'exploitation.
- Désactivation permanente de la capacité d'appel arbitraire qui a rendu possible le résultat « exécutez n'importe quel calldata que le protocole signe ».
- Remplacement des modèles d'approbation illimitée dans les flux de dépôt par des approbations de montant exact, de sorte qu'une seule approbation ne puisse pas rester silencieusement utilisable des mois plus tard.
Le thème le plus important est le passage d'une « généralité puissante mais dangereuse » à une « intention étroite et vérifiable ». Les protocoles inter-chaînes qui souhaitent s'adapter en toute sécurité en 2026 devront de plus en plus utiliser par défaut des cibles sur liste blanche, des messages typés et une exécution limitée en capacité.
Points à retenir pour les développeurs : la sécurité inter-chaînes en 2026 concerne la composition, pas les composants
Même en dehors de ZetaChain, les systèmes inter-chaînes continuent d'être attaqués car ils se situent à l'intersection de :
- machines à états complexes,
- signature/validation distribuée,
- et interfaces de jetons hautement monétisables.
Les rapports de pertes de l'industrie continuent de montrer que la gravité des exploitations reste élevée et que les événements de risque extrême dominent les résultats (voir un exemple de suivi agrégé de l'industrie dans : Rapport d'Immunefi « Pertes de crypto au 1er trimestre 2025 » (PDF)).
Si vous concevez ou intégrez de la messagerie inter-chaînes, considérez ces garde-fous pratiques :
- Rendez l'origine des messages explicite et authentifiée : « N'importe qui peut demander un appel inter-chaînes » ne devrait jamais équivaloir à « le protocole le signera et l'exécutera ».
- Évitez les listes noires pour les points d'exécution : privilégiez les listes blanches et les interfaces minimales.
- Traitez les allocations comme faisant partie de votre modèle de menace : les portefeuilles du trésor/opérateurs doivent avoir des politiques d'approbation strictes, une surveillance et un nettoyage périodique.
- Prévoyez une coordination d'urgence : les réseaux de réponse aux incidents comme SEAL 911 existent car chaque minute compte lorsqu'il s'agit de signatures et d'exécution inter-chaînes.
Liste de contrôle utilisateur : que faire après tout incident inter-chaînes (même si « les utilisateurs n'ont pas été affectés »)
Même lorsqu'un protocole affirme que les fonds des utilisateurs n'ont pas été affectés, il est rationnel de prendre 10 minutes pour réduire votre rayon d'explosion personnel, surtout si vous avez déjà interagi avec les contrats de passerelle concernés.
1) Révocquer les allocations dont vous n'avez pas activement besoin
Deux options fiables :
- Utilisez un outil de gestion des approbations tel que Guide d'approbation de jeton Revoke.cash
- Ou utilisez le vérificateur intégré d'un explorateur de blocs comme Vérificateur d'approbation de jeton Etherscan
2) Se défendre contre l'empoisonnement d'adresses dans le comportement quotidien
- Ne copiez pas les destinataires de l'historique des transactions.
- Utilisez des carnets d'adresses / contacts de confiance dans la mesure du possible.
- Vérifiez plus que les premiers/derniers caractères : les attaques d'empoisonnement sont conçues pour correspondre à ce que les interfaces des portefeuilles tronquent.
3) Utiliser la vérification d'adresse basée sur le matériel pour les transferts de grande valeur
Un portefeuille matériel ne peut pas arrêter un bug de contrat intelligent sur un protocole que vous ne contrôlez pas, mais il peut réduire la probabilité que vous autorisiez personnellement le mauvais destinataire lors d'un scénario d'empoisonnement d'adresse ou de manipulation de presse-papiers.
C'est là que OneKey s'intègre naturellement : en maintenant la signature isolée et en mettant l'accent sur la vérification sur appareil, il aide à rapprocher « ce que vous signez » de « ce que vous avez l'intention » — surtout dans les moments stressants où les attaquants tentent d'exploiter la confusion.
Réflexions finales
L'exploit de ZetaChain est une étude de cas compacte de la réalité moderne de la sécurité des cryptos :
- un problème signalé précédemment,
- rejeté en raison d'une hypothèse « par conception »,
- combiné à une exécution permissive et des approbations restantes,
- exécuté par un attaquant qui avait préparé à l'avance le financement, les outils et le bruit au niveau social.
Si 2025-2026 a enseigné quoi que ce soit à l'industrie, c'est que les systèmes inter-chaînes doivent être conçus pour la composition adverse. La fonctionnalité la plus sûre est celle que vous ne pouvez pas accidentellement transformer en oracle de signature, même lorsque tout « fonctionne comme prévu ».
