Gnosis Pay : le bug était déjà corrigé sur GitHub

Le bug qui a vidé environ 265 000 dollars de Gnosis Pay le 1er juin 2026 était déjà corrigé dans le code source depuis le 27 février. Le correctif existait, il était fusionné, public et vérifiable sur GitHub. Ce qui a échoué n'est pas la détection de la faille, mais sa propagation : le contrat déployé sur la chaîne n'a jamais reçu la correction car il était toujours compilé avec une dépendance ancienne. Cet article n'est pas un simple rapport de piratage DeFi de plus. C'est une étude de cas sur un schéma structurel que presque personne n'audit : l'écart entre un « bug corrigé dans le dépôt » et un « bug actif on-chain ». Le module concerné, le Zodiac Delay Module (un module de gouvernance qui impose un délai obligatoire entre l'approbation d'une transaction et son exécution pour permettre un veto), est open-source, audité et utilisé par des dizaines de protocoles. Pourtant, le code qui protégeait les fonds n'était pas le code qui tournait sur la blockchain. Nous allons reconstruire la chronologie exacte, expliquer pourquoi « open-source et audité » ne signifie pas « sécurisé en production » et proposer une checklist exploitable pour vérifier que le contrat déployé intègre réellement les derniers correctifs.

Que s'est-il passé exactement le 1er juin ?

Le 1er juin 2026, Gnosis Pay — la carte de débit auto-dépositaire qui dépense le solde directement depuis une Safe (wallet de contrat intelligent multisig) de l'utilisateur — a détecté un exploit actif contre le Zodiac Delay Module v1.1.0 déployé sur Gnosis Chain. L'attaquant a drainé environ 265 000 dollars répartis entre plusieurs victimes avant que l'équipe ne se coordonne avec les validateurs du bridge pour suspendre les opérations et contenir le mouvement des fonds.

Le mécanisme du module est, sur le papier, une couche de protection. Lorsqu'un utilisateur souhaite déplacer des fonds en dehors du flux normal de paiement par carte, la transaction est mise en file d'attente et doit attendre une période de refroidissement (cooldown) avant d'être exécutée. Durant cet intervalle, une transaction malveillante peut être marquée comme invalide et faire l'objet d'un veto. C'est l'équivalent d'un virement bancaire programmé que vous pouvez annuler dans une fenêtre de sécurité. Le Delay Module transforme cette fenêtre en code.

L'exploit n'a pas brisé la logique du délai de manière frontale. Il a attaqué la vérification des signatures. Le Delay Module — comme une grande partie de l'écosystème Safe — valide certaines opérations via le standard ERC-1271 (le mécanisme par lequel un contrat intelligent, et pas seulement une clé privée, peut « signer » et autoriser une action). La faille permettait qu'un appel de contrat ayant échoué (revert) soit tout de même interprété comme une signature valide. L'attaquant contrôlait les données renvoyées par cet appel défaillant et, avec elles, fabriquait une autorisation que le module acceptait comme légitime.

Pourquoi une faille de 2023 a-t-elle explosé en 2026 ?

C'est ici que cela devient intéressant, et où la chronologie cesse d'être un simple rapport d'incident pour devenir une étude de cas. Le bug n'est pas né en juin 2026. Selon la reconstruction forensique de Verichains, la vulnérabilité a été introduite le 28 octobre 2023, dans le commit 9a9e380 du code de Zodiac.

Ce commit a modifié la façon dont le contrat gérait un staticcall (un appel en lecture seule vers un autre contrat, qui ne doit pas modifier l'état). Lors de la modification, la valeur success — le booléen indiquant si l'appel a réussi ou échoué — a été écartée, ne laissant que la vérification de la « valeur magique » dans les données de retour. Traduction : le contrat a cessé de demander « est-ce que cet appel a fonctionné ? » pour ne plus demander que « est-ce que les données que tu me renvoies ont la bonne forme ? ». Comme l'attaquant contrôlait ces données de retour même lors d'un appel en échec, il pouvait construire une réponse avec la forme correcte à partir d'une opération qui avait en réalité échoué.

Pendant deux ans et demi, cette faille est restée latente. Elle n'a pas été exploitée car elle n'était pas triviale à trouver et nécessitait une combinaison précise de conditions : un compte avec le Delay Modifier v1.1.0 (ou le Roles Modifier v2) activé, associé à une Safe utilisant un fallback handler (le contrat qui gère les appels non prévus explicitement) vulnérable et assigné comme module ou comme membre de rôle. Une configuration spécifique, mais exactement celle de l'infrastructure de Gnosis Pay.

Qu'était le « correctif fantôme » de février ?

Le 27 février 2026 — trois mois avant l'exploit — l'équipe de Zodiac a corrigé la faille. Le commit de fusion 11708ac dans le dépôt gnosisguild/zodiac-core — la pull request #34, « Simplify Base Contracts », faisant partie de la version v4.0.0-alpha.0 — a réécrit les contrats de base. Parmi ses changements, le sous-commit f06f07b a ajusté la validation EIP-1271 « pour vérifier le succès du staticcall » : c'est-à-dire qu'il a réintroduit la question que le commit de 2023 avait supprimée, « est-ce que cet appel a réellement fonctionné ? ».

Le correctif était correct. Il était public. Il était sur GitHub, fusionné dans la branche principale, accessible à quiconque voulait le lire. Et il n'a servi à rien, car le contrat qui gardait l'argent de Gnosis Pay ne l'a jamais reçu.

La raison relève de la gestion des dépendances, pas de la cryptographie. La nouvelle ligne de code corrigée vivait dans le paquet zodiac-core. Mais les instances du Delay Module en production étaient toujours compilées avec l'ancien paquet, @gnosis.pm/zodiac, une dépendance legacy qui n'a jamais reçu le backport du correctif. L'écosystème s'était fragmenté en deux lignées de code : la nouvelle, où le bug était mort, et l'ancienne, toujours en usage, où il restait vivant. La question forensique posée par Verichains est exactement celle-ci : pourquoi les instances de Gnosis Pay en production étaient-elles encore compilées avec une dépendance obsolète alors qu'il existait une version plus récente ayant déjà résolu ce type de bug ?

Pourquoi un fix dans le dépôt n'est pas un fix en production ?

C'est le cœur du sujet et la partie que la couverture médiatique superficielle a ignorée en titrant « Gnosis Pay a été hacké ». Un contrat intelligent ne se met pas à jour tout seul quand quelqu'un fusionne une pull request sur GitHub. Le bytecode qui tourne sur la blockchain est une photographie immuable du code tel qu'il était au moment du déploiement. Fusionner un correctif en amont (upstream) ne touche pas à ce bytecode. Pour que le fix arrive sur la chaîne, quelqu'un doit recompiler avec la version corrigée et redéployer le contrat (ou, dans les architectures évolutives, pointer le proxy vers une nouvelle implémentation). Tant que cela n'est pas fait, le dépôt et la chaîne divergent.

L'analogie est celle de n'importe quel déploiement logiciel moderne. Une équipe corrige une faille de sécurité dans une bibliothèque et publie une nouvelle version. Votre service en production n'est pas protégé par magie : il continue d'exécuter l'image du conteneur construite il y a des mois, avec la vieille version de la bibliothèque empaquetée à l'intérieur, jusqu'à ce que vous refassiez le build et le déploiement. La différence est que dans le cloud, redéployer est une commande de routine ; on-chain, c'est une opération coûteuse, parfois irréversible, qui peut nécessiter une gouvernance, une migration des utilisateurs ou une pause du système. L'incitation à ne pas toucher à ce qui « fonctionne » est bien plus forte. C'est pourquoi l'écart entre le dépôt et la production a tendance à s'élargir avec le temps, plutôt qu'à se combler.

Il y a un facteur aggravant de transparence que presque personne ne mentionne. Un correctif public dans un dépôt open-source est, pour un attaquant attentif, une carte. Le commit qui corrige un bug décrit le bug. Quiconque surveille les dépôts des bibliothèques de sécurité les plus utilisées peut lire un fix, en déduire la vulnérabilité qu'il corrige et vérifier quels contrats en production ne l'ont toujours pas appliqué. La transparence qui rend l'open-source fiable est, dans la fenêtre entre le fix et le redéploiement, précisément l'indice dont l'adversaire a besoin.

En quoi le modèle mental « open-source et audité » est-il erroné ?

Le cas de Gnosis Pay démonte plusieurs croyances confortables sur les raisons pour lesquelles un système crypto « devrait » être sûr. Il convient de les confronter à la réalité opérationnelle.

Aucune de ces croyances n'est absurde. Elles sont toutes raisonnables comme point de départ. Le problème est de les traiter comme des garanties plutôt que comme des conditions nécessaires mais insuffisantes. « Audité » réduit le risque ; il ne l'élimine pas, et ne couvre certainement pas la divergence ultérieure entre ce qui a été audité et ce qui est déployé.

Comment Gnosis, Zodiac et Safe ont-ils répondu ?

La réponse à l'incident a été, sur le plan procédural, rapide et raisonnablement transparente. Gnosis a suspendu le bridge en se coordonnant avec les validateurs pour freiner la sortie des fonds. Le cofondateur Martin Köppelmann s'est engagé à rembourser intégralement les utilisateurs concernés : « Gnosis couvrira toutes les pertes des utilisateurs », a-t-il publié sur X.

L'équipe de Zodiac a communiqué qu'elle travaillait directement avec les comptes concernés avant la divulgation publique et que, au moment où l'avis a été rendu public, plus de 95 % des comptes concernés identifiables avaient déjà pris des mesures correctives. Safe Labs, de son côté, s'est empressé de clarifier le périmètre de la faille : les contrats intelligents de Safe, l'infrastructure et l'interface de Safe{Wallet} ainsi que la récupération de comptes n'étaient pas affectés. La vulnérabilité était isolée dans des modules tiers de Zodiac — le Roles Modifier v2 et le Delay Modifier v1.1.0 — et ne s'activait que sous la combinaison précise de conditions décrite précédemment.

Cette distinction est importante pour ne pas surdimensionner le risque systémique : ce n'était pas une faille dans le cœur de Safe, qui soutient une fraction énorme des actifs en contrats intelligents de l'écosystème. Mais il ne convient pas non plus de la sous-dimensionner : les modules de Zodiac sont utilisés par de nombreux protocoles pour la gouvernance et la gestion de trésorerie, et la leçon sur la lignée des dépendances s'applique à tous.

Comment vérifier que le contrat déployé porte les derniers correctifs ?

La valeur exploitable de ce cas est que l'écart entre le dépôt et la production est auditable. Ce n'est pas une fatalité invisible. Tant un protocole qui intègre des modules tiers qu'un utilisateur avancé qui confie des fonds à un contrat peuvent vérifier une grande partie de ce qui a échoué ici. Voici la checklist minimale.

• Identifiez la version exacte déployée, pas celle du dépôt. Lisez sur l'explorateur de blocs le code vérifié du contrat en production et notez avec quelle version de la bibliothèque il est compilé. Le numéro qui compte est celui du bytecode on-chain, pas celui du README de GitHub.
• Vérifiez la lignée du paquet. Distinguez si le contrat dépend du paquet actif ou d'un paquet legacy. Dans ce cas, la différence entre zodiac-core et @gnosis.pm/zodiac a été la différence entre être protégé et ne pas l'être. Un paquet déprécié peut ne pas recevoir de backports de sécurité.
• Suivez les commits de sécurité des bibliothèques que vous utilisez, pas seulement leurs releases. Un fix peut arriver dans une version alpha ou dans un commit isolé des mois avant une release « officielle ». Surveillez l'historique, pas uniquement les étiquettes de version.
• Traitez chaque correctif upstream comme une tâche de redéploiement, pas comme un événement déjà résolu. Fusionner n'est pas déployer. Maintenez un inventaire des contrats en production qui dépendent de quelles bibliothèques et avec quelle version, pour savoir ce qu'il faut redéployer lorsqu'un fix apparaît.
• Lorsqu'un correctif public apparaît dans une bibliothèque que vous utilisez, considérez que c'est une information publique aussi pour l'attaquant. La fenêtre entre le fix et votre redéploiement est une course. Priorisez-la comme telle.
• En tant qu'utilisateur, minimisez le solde à chaud. Si un produit conserve des fonds dans un contrat avec des modules complexes, ne gardez on-chain que ce que vous allez utiliser à court terme et vérifiez quels modules sont activés sur votre Safe.

Aucune de ces étapes ne nécessite d'être auditeur. Elles nécessitent de traiter le déploiement comme faisant partie de la surface de sécurité, et pas seulement le code.

Quel modèle ce cas laisse-t-il pour le reste de la DeFi ?

L'exploit de Gnosis Pay est le revers de la médaille des attaques sur la chaîne d'approvisionnement logicielle qui ont marqué 2026. Dans ces dernières, du code malveillant s'insère dans une dépendance et se propage vers la production sans que personne ne le veuille. Ici, c'est l'inverse qui s'est produit et, d'une certaine manière, c'est plus dérangeant : du code légitime et correctif existait, mais il ne s'est pas propagé. L'échec n'est pas venu des développeurs qui ont trouvé et corrigé le bug. Il est venu de la chaîne qui devait porter ce correctif du dépôt jusqu'au bytecode qui gardait l'argent.

La leçon structurelle est que la sécurité d'un système crypto ne se décide pas seulement dans le code ni seulement dans l'audit. Elle se décide aussi, et peut-être surtout, dans la discipline de déploiement : savoir quelle version tourne sur la chaîne, avec quelles dépendances elle est compilée et avec quel retard par rapport aux correctifs connus. Dans un écosystème qui se targue de transparence, la donnée la plus opaque est souvent précisément celle-là : la distance entre ce que dit le dépôt et ce qu'exécute le contrat. Celui qui la mesurera aura un avantage de sécurité réel sur celui qui se contentera du label « open-source et audité ».

Sources et liens : Verichains — post-mortem technique · GitHub gnosisguild/zodiac-core · The Defiant · CryptoTimes