Aztec Connect : 2,19 M$ volés d'un contrat mort

Un contrat qui était resté impossible à patcher pendant plus de deux ans par décision de sa propre équipe a perdu environ 2,19 millions de dollars en une seule transaction. Le 14 juin 2026, un attaquant a vidé le contrat RollupProcessor d'Aztec Connect — un pont de confidentialité sur Ethereum qu'Aztec Labs avait déprécié (retiré du service). Aztec Connect avait annoncé sa fermeture en mars 2023 (dépôts interrompus le 31 mars) et avait renoncé aux admin keys (les clés d'administration permettant de modifier ou de suspendre un smart contract) un an plus tard, en mars 2024, lors de l'arrêt du séquenceur. Entre cette renonciation aux clés — le moment où le contrat est devenu réellement impossible à patcher — et l'exploit, environ deux ans et trois mois se sont écoulés. L'équipe a fait ce que la communauté considère comme « la bonne chose » : faire en sorte que personne, pas même eux, ne puisse y toucher. Le problème est que l'argent était toujours à l'intérieur. Cet article analyse pourquoi déprécier un protocole et le laisser immuable avec des fonds actifs ne relève pas d'une sécurité maximale, mais constitue un bug latent transformé en bombe sans désamorceur, et ce que devrait inclure une fermeture responsable.

Que s'est-il passé exactement chez Aztec Connect le 14 juin ?

Le 14 juin 2026, un attaquant a interagi avec le contrat RollupProcessor d'Aztec Connect sur Ethereum et a extrait, en une seule transaction atomique (tout ou rien, sans étapes intermédiaires réversibles), un panier d'actifs évalué à environ 2,19 millions de dollars. Selon le détail publié par SlowMist (société de cybersécurité blockchain basée en Chine, connue pour ses analyses forensiques de hacks DeFi), le butin comprenait de l'ETH, du DAI, du wstETH, du LUSD et plusieurs vaults de Yearn (yvDAI, yvWETH, yvLUSD). Les fonds ont transité du contrat vers un contrat-pont intermédiaire, puis vers un wallet externe contrôlé par l'attaquant.

Une donnée mérite d'être soulignée : à la clôture des analyses techniques, et selon SlowMist, 100 % des fonds étaient toujours intacts à l'adresse de l'attaquant, sans que le processus de blanchiment n'ait commencé. C'est pertinent car cela signifie qu'il ne s'agissait pas d'un vol désespéré pour déplacer les fonds rapidement, mais de l'exploitation sereine d'une cible qui n'était plus surveillée depuis des années.

Aztec Labs et la Aztec Foundation ont confirmé que le contrat exploité n'a aucun lien avec le token AZTEC ni avec les smart contracts du réseau Aztec actuel. Les dommages sont restés confinés au produit legacy. Mais l'épisode ne s'est pas arrêté là : trois jours plus tard, un second coup est survenu.

Y a-t-il eu un second exploit et pourquoi la chronologie est-elle importante ?

Le 17 juin 2026, un second incident a touché un autre contrat legacy de l'écosystème Aztec — décrit par plusieurs sources comme un mécanisme de retrait d'urgence (escapeHatch) d'un pont de rollup privé également déprécié. Les montants rapportés varient entre 2,15 et 2,21 millions de dollars selon la source (Coinpedia l'a chiffré à environ 2,16 M$ ; CryptoTimes à environ 2,21 M$), soit une moyenne de ~2,16 M$ entre les sources. Ajoutés aux 2,19 millions du premier coup, des médias comme CoinJournal et NullTX ont chiffré les pertes à plus de 4 millions de dollars en trois jours via deux systèmes legacy distincts.

BlockSec (société d'analyse on-chain et d'audit de smart contracts) a décrit les deux incidents comme étant liés à des « problèmes de liaison des public inputs » (la manière dont le contrat lie les données d'entrée d'une preuve cryptographique à ce qui est réellement liquidé), tout en précisant que les méthodes d'attaque n'étaient pas identiques. La chronologie est importante car elle dessine un schéma : une même équipe, plusieurs contrats arrêtés il y a des années, tous impossibles à patcher, tous avec un solde positif, tombant les uns après les autres en quelques jours. Ce n'est pas de la malchance ; c'est le résultat prévisible d'une décision de conception.

Note de prudence : les chiffres exacts du second incident et le total agrégé n'étaient pas encore consolidés entre toutes les sources à la clôture de cet article. Nous les traitons comme des rapports attribués, et non comme des chiffres définitifs.

Pourquoi un contrat déprécié en 2023 contenait-il encore des millions ?

C'est ici que réside le paradoxe qui donne tout son sens à l'affaire. Aztec Connect était un pont qui permettait aux utilisateurs de déplacer des actifs vers un environnement privé sur Ethereum et d'opérer avec eux. Lorsqu'Aztec Labs a décidé de pivoter vers un nouveau réseau, elle a annoncé la fermeture du produit en mars 2023, a coupé les dépôts le 31 mars et a ouvert une fenêtre pour que les utilisateurs retirent leurs fonds. Un an plus tard seulement, en mars 2024 — après la fermeture de cette fenêtre —, elle a éteint le séquenceur et a renoncé aux admin keys, gelant le contrat de manière définitive.

Mais « ouvrir une fenêtre de retrait » n'est pas la même chose que « vider le contrat ». Il y a toujours des utilisateurs qui ne sont pas au courant, qui ont perdu leurs clés, qui ont considéré l'argent comme perdu ou qui n'ont tout simplement pas agi. Deux ans après avoir soudé la porte, ce reliquat — l'argent des personnes qui ne sont jamais revenues — était toujours déposé dans un contrat que plus personne n'exploitait. Dans le jargon, il s'agit d'une TVL (total value locked) orpheline : du capital actif à l'intérieur d'un code mort.

• Le produit était mort : aucune équipe assignée, aucune surveillance active, aucun nouvel audit.
• L'argent était vivant : ETH, stablecoins et actifs à rendement, parfaitement extractibles pour quiconque trouverait la faille.
• Le contrat était immuable : ni l'équipe ni personne ne pouvait retirer ce reliquat, le suspendre ou le patcher.

Cette combinaison — inattention + solde + immuabilité — est exactement ce qui transforme un protocole déprécié en une cible qui se bonifie avec le temps. Plus le temps passe, moins il y a de regards pour le surveiller et plus on oublie que l'argent est toujours là.

Comment a fonctionné l'exploit du boundary gap ?

Imaginez un contrôle de sécurité d'aéroport avec 32 portes à la suite, mais un seul garde qui ne se trouve physiquement qu'à la dernière. La règle de l'aéroport stipule que « tous les passagers passant par ces portes sont enregistrés comme vérifiés ». Le système d'enregistrement note effectivement les 32 comme vérifiés. Mais le garde, en pratique, ne contrôle que celui qui franchit sa porte. Les 31 autres portes sont enregistrées comme contrôlées sans que personne ne les contrôle réellement.

C'est, par essence, ce qui s'est passé. Dans un système de ZK-rollup (une technologie qui regroupe de nombreuses transactions, génère une preuve cryptographique de leur validité et l'inscrit sur Ethereum), deux pièces doivent s'emboîter :

• La preuve cryptographique indique combien d'opérations sont engagées dans le nouvel état. Dans le contrat, ce nombre est lié aux slots de données — 32 au total dans chaque lot.
• Le contrat de liquidation sur Ethereum (la couche L1, où l'argent change réellement de mains) parcourt ces opérations pour déplacer les fonds et devrait vérifier chacune d'elles.

La faille, selon SlowMist et BlockSec, résidait dans une divergence entre les deux plages : ce que la preuve engageait comme état valide (le registre qui dit « 32 vérifiés ») et ce que la boucle de liquidation de la L1 vérifiait réellement (le garde qui ne regarde qu'une porte). Le terme technique est boundary gap : un vide à la frontière entre la vérification off-chain de la preuve et la vérification on-chain du règlement.

En pratique, l'attaquant a réussi à faire en sorte que 31 des 32 slots soient engagés dans l'état L2 par la preuve sans passer par aucune vérification de liquidation dans le contrat L1. Il a inséré des instructions de retrait par ces 31 portes « enregistrées mais non contrôlées » et le contrat a libéré les fonds, croyant que tout était validé. Et comme le contrat était immuable, il n'y avait aucun moyen de fermer la porte une fois découverte.

L'aspect crucial de ce type de faille est qu'il ne s'agit pas d'une erreur de programmation grossière, du style d'un require oublié ou d'une fonction publique qui devrait être privée. C'est un défaut de conception de la frontière : deux composants qui fonctionnent bien individuellement — la génération de la preuve et la boucle de liquidation — mais dont les hypothèses sur « ce qui compte comme vérifié » ne coïncident pas exactement. Ces lacunes aux limites sont notoirement difficiles à détecter lors d'un audit car chaque pièce semble correcte séparément ; le trou n'apparaît que lorsqu'on les examine ensemble et sous une transaction construite à dessein. C'est pourquoi SlowMist insiste sur l'audit de la cohérence logique de la bordure L1/L2 et la vérification secondaire on-chain des public inputs comme une catégorie de risque à part entière, et non comme un simple détail du code.

Pourquoi renoncer aux admin keys peut être une erreur ?

C'est la thèse inconfortable de cet article. L'intuition dominante dans l'univers crypto est que renoncer aux admin keys équivaut à une sécurité maximale : « personne ne peut toucher au contrat, pas même l'équipe, donc personne ne peut voler ni censurer ». Pour un protocole de confidentialité, cela possède en plus un fort attrait idéologique : l'absence d'administrateur est la preuve qu'il n'y a pas de porte dérobée.

Le problème est que l'immuabilité est une épée à double tranchant. Immuable signifie aussi impossible à patcher. Renoncer aux clés élimine le risque qu'un administrateur malveillant (ou compromis) vole les fonds, mais en échange, cela élimine aussi le seul outil permettant de réagir lorsqu'un bug apparaît. Et le code sans bug n'existe pas ; il n'existe que du code avec des bugs qui n'ont pas encore été trouvés.

Tant qu'un protocole est actif, ce pari peut avoir du sens : il y a une équipe qui surveille, une communauté, des audits, des bug bounties. Mais un protocole déprécié perd tout cela et conserve le pire : le solde et l'impossibilité d'agir. Renoncer aux clés sans avoir d'abord vidé les fonds ne revient pas à remettre les clés d'un coffre-fort vide ; c'est souder la porte d'un coffre-fort plein et jeter le chalumeau. Le jour où quelqu'un trouve comment l'ouvrir par un côté, il n'y a personne ayant l'autorité — ni la capacité technique — pour le défendre.

Le cas miroir le démontre à l'autre extrême. Fin mai 2026, les lockers legacy de DxSale (plateforme de lancement de tokens et de verrouillage de liquidité sur BNB Chain) ont perdu environ 7,3 millions de dollars, mais pour la raison opposée : on n'avait pas renoncé aux admin keys, elles avaient été transférées discrètement des mois auparavant et ont été utilisées de manière abusive pour vider plus de 1 400 pools. Aztec a renoncé aux clés et s'est fait voler par un bug ; DxSale a conservé les clés et s'est fait voler par les clés. Le facteur commun n'est pas les clés : c'est l'argent resté à l'intérieur d'un système dont plus personne ne s'occupait. Le vecteur change ; la cause profonde est la même.

Comment cela se compare-t-il à d'autres cas de « code mort » ?

Aztec Connect n'est pas le premier protocole legacy à saigner des années après sa mort. Le tableau résume trois épisodes récents de 2026 où le dénominateur commun est du capital actif dans une infrastructure délaissée, avec des vecteurs différents.

La lecture croisée est celle qui donne le titre : renoncer aux clés (Aztec) ou les conserver mal gardées (DxSale) aboutit au même résultat lorsqu'il y a un solde dans un système que personne n'exploite. La gouvernance des clés est secondaire ; l'erreur primaire est de ne pas avoir retiré les fonds lors de la fermeture. Un contrat déprécié et vide n'apparaît sur aucune liste de cibles.

Il existe en outre un biais temporel qui aggrave le cas des contrats immuables par rapport à ceux dont l'administrateur est compromis. Un contrat avec un administrateur actif reçoit des patchs, des rotations de clés et une surveillance tant que quelqu'un l'exploite ; sa surface d'attaque peut se réduire avec le temps. Un contrat immuable et déprécié fait le contraire : sa surface d'attaque ne fait que croître, car le code est gelé le jour de la fermeture alors que les techniques d'analyse et les outils des attaquants continuent de s'améliorer année après année. Le contrat d'Aztec Connect était, en 2026, exactement aussi sûr que lorsqu'il a été gelé en mars 2024 — mais le monde qui l'entourait était bien plus performant pour trouver des failles. Le temps joue contre le code qui ne peut pas changer.

Comment devrait-on déprécier un protocole de manière responsable ?

Le secteur traite le « déprécier et oublier » comme une opération neutre : on annonce la fermeture, on ouvre une fenêtre de retrait et on considère l'affaire classée. Mais tant qu'il reste un solde, le protocole demeure un passif de sécurité. Une fermeture responsable — un sunset bien fait — devrait traiter le reliquat comme le problème central, et non comme un détail.

• Retrait forcé du reliquat : conserver la capacité technique de balayer les fonds non réclamés (vers un contrat de garde, un multisig de la fondation — un contrat exigeant plusieurs signatures pour déplacer des fonds, sans point de défaillance unique — ou un mécanisme de réclamation ultérieur) avant de souder la porte. Un contrat vide est immunisé par définition.
• Renonciation aux clés après, pas avant : l'immuabilité comme dernière étape, une fois que la TVL est à zéro ou à un minimum accepté, et non comme un geste symbolique le jour de l'annonce.
• Bouton de pause conservé pendant la transition : maintenir un bouton de pause (pause button : une fonction qui gèle le contrat sans permettre de déplacer les fonds) avec time-lock (un délai public avant que toute action ne prenne effet) pendant toute la durée de la fenêtre, afin de pouvoir geler le contrat si une faille apparaît sans pouvoir déplacer les fonds arbitrairement.
• Audit de l'état de fermeture : auditer spécifiquement le chemin de retrait d'urgence et les bordures L1/L2, là où les deux contrats d'Aztec ont précisément échoué.
• Surveillance post-mortem : si, par conception, on ne peut pas agir, au moins surveiller le contrat mort et avertir publiquement du solde résiduel, pour que le risque soit explicite et non une mine enterrée.

SlowMist, dans sa propre analyse, recommande exactement cela pour les contrats dépréciés qui détiennent encore des actifs : une migration ordonnée ou la destruction des fonds pour éliminer l'exposition continue. La leçon n'est pas « ne renoncez pas aux clés » ; c'est « ne laissez pas d'argent derrière une porte que vous décidez de ne plus pouvoir rouvrir ».

Quelles leçons pour le lecteur ?

Pour l'utilisateur de la DeFi, l'épisode laisse une règle concrète : lorsqu'un protocole annonce sa fermeture, la fenêtre de retrait est le seul moment où le système a encore quelqu'un pour s'en occuper, et un solde oublié dans un contrat déprécié n'est pas « gardé », mais exposé et sans personne capable de le défendre. L'intuition à corriger est d'assimiler « immuable » à « sûr » : l'immuabilité protège contre l'administrateur malveillant mais vous laisse sans défense face au bug sans patch, et dans un protocole mort — sans surveillance et avec de l'argent à l'intérieur — on obtient la pire combinaison possible. C'est pourquoi la recommandation que SlowMist tire de l'affaire n'est pas « ne renoncez pas aux clés », mais de migrer ou de détruire les actifs des contrats legacy qui détiennent encore des fonds avant de souder la porte : « protocole mort, argent vivant » reste l'une des surfaces d'attaque les plus mal gérées de la DeFi, précisément parce qu'elle se déguise en bonne pratique.

Sources et liens : SlowMist — analyse technique de l'exploit · NewsBTC — risque de traîne longue des contrats dépréciés · Cryptopolitan · CoinJournal — second incident · Crypto Briefing · Rekt News — DxSale