Attaque de gouvernance | Financial Context Wiki

Une attaque de gouvernance acquiert assez de pouvoir de vote ou d'exécution pour faire adopter des changements nuisibles par la voie autorisée.

À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

Réponse directe

Une attaque de gouvernance acquiert assez de pouvoir de vote, de proposition, d’annulation ou d’exécution pour amener un protocole à réaliser une action nuisible par sa voie de gouvernance autorisée. Les appels peuvent satisfaire tous les contrôles des contrats intelligents. La défaillance tient au fait que le contrôle peut être acquis trop facilement, trop vite ou sans responsabilité suffisante par rapport à la valeur placée sous ce contrôle.

Le pouvoir de vote peut provenir de jetons détenus, de voix déléguées, de jetons empruntés, d’électeurs soudoyés, de clés compromises ou de rôles privilégiés du gouverneur et du timelock. Les points de contrôle historiques empêchent un même solde de voter de nouveau après un transfert et peuvent bloquer un emprunt postérieur au snapshot. Ils n’empêchent ni les voix obtenues avant celui-ci, ni la concentration des délégations, ni un quorum faible, ni un exécuteur compromis.

Toute proposition impopulaire n’est pas une attaque : la gouvernance sert à changer les règles. Il faut déterminer si un acteur a obtenu un contrôle disproportionné ou temporaire, a caché ou déformé l’effet exécutable, ou a franchi une limite d’autorité annoncée publiquement. L’analyse porte sur les appels réels, la voie la moins chère vers le pouvoir décisif, le temps de réaction et la valeur ou le contrôle maximal accessible après exécution.

Fonctionnement

Cartographier l’autorité depuis l’actif de vote, via les délégations et points de contrôle, jusqu’au gouverneur, au timelock, à l’administrateur du proxy, à la trésorerie, aux rôles d’urgence et aux contrats cibles. L’interface de gouvernance n’est pas le graphe des permissions.
Fixer chaîne, adresses, versions d’implémentation, mode d’horloge, snapshot, seuil de proposition, calcul du quorum, règle de dépouillement, délai et période de vote, délai de mise en file, expiration, droits d’annulation et rôles d’exécution.
Reconstituer le pouvoir de vote au snapshot exact avec des lectures historiques comme getPastVotes. Regrouper les adresses contrôlées ou coordonnées par un même acteur et séparer le solde de jetons du poids délégué.
Décoder chaque action : targets, values, calldatas et descriptionHash. Résoudre proxies et sélecteurs, examiner les appels groupés et comparer la charge exécutable à la description lisible.
Reproduire sur un fork la création, le vote, la mise en file et l’exécution. Comparer avant et après soldes, propriété, rôles, autorisations, implémentations, réglages des oracles, paramètres de garantie et toute fonction nouvellement accessible.
Évaluer la voie de contrôle la moins chère parmi achats au comptant, marchés de prêt, liquidité flash, prêts de gré à gré, délégation, incitations au vote, couvertures dérivées, compromission de clés et capture de rôles privilégiés. Inclure frais, glissement, garantie, pertes de débouclage et durée d’immobilisation du capital.
Tester la réaction. Confirmer qui peut annuler ou suspendre, quelles preuves sont requises, si l’action tient dans le délai, où les utilisateurs trouvent les avis officiels et comment la gouvernance reprend sans laisser une clé d’urgence illimitée.

Un gouverneur de jetons classique passe par proposition, délai, snapshot, vote, adoption ou rejet, file, timelock et exécution. Les règles exactes dépendent de l’implémentation. Avec des points de contrôle de type ERC-5805, le poids délégué peut être interrogé à un instant passé ; l’horloge peut utiliser des blocs ou des horodatages. Il faut employer l’horloge et la configuration déployées, sans supposer que la durée affichée ou le solde font foi.

Un timelock crée un délai minimal d’information, mais ne juge pas l’intention et ne sécurise pas la charge. Ses rôles de proposant, exécuteur, annulateur et administrateur sont eux-mêmes critiques. Si un administrateur externe peut contourner le délai, le timelock n’est pas l’autorité finale. Si personne ne peut annuler une action malveillante en file, sa détection n’empêche pas son exécution.

Exemples chiffrés

Capture avec faible participation. Un protocole compte 100 million jetons au total et 40 million en circulation. Une proposition exige 2 million voix participantes, plus de voix pour que contre et un timelock de 6-hour. Un acteur achète 1.2 million voix et en reçoit 1 million par délégation. Les voix contre totalisent 0.8 million ; ses 2.2 million voix pour adoptent donc un appel capable de transférer 15 million USDC depuis la trésorerie. Il contrôle 2.2 / 100 = 2.2% de l’offre totale et 2.2 / 40 = 5.5% de l’offre en circulation, mais 2.2 / 3.0 = 73.3% des suffrages exprimés. Les paramètres décisifs sont participation, délégation, quorum, autorité de la charge et délai, pas le slogan 51%.
Limite du snapshot. Si le poids est lu dans le solde courant et que l’exécution est immédiate, une transaction peut emprunter les jetons, voter, exécuter et rembourser. Lire un poids historique immuable antérieur au vote bloque cette voie atomique. Le capital emprunté ou délégué avant le snapshot reste utilisable ; le délai de proposition et la fenêtre observable d’acquisition demeurent donc des défenses.
Beanstalk le 17 avril 2022. Beanstalk Farms a indiqué qu’un attaquant avait utilisé un prêt flash pour exploiter la gouvernance du protocole et dérober environ $77 million d’actifs d’utilisateurs hors Beanstalk. Le cas montre que la liquidité flash finance l’attaque, tandis que la faiblesse décisive permet au pouvoir économique temporaire d’atteindre des permissions d’exécution de grande valeur.

Risques et contrôles

Pouvoir effectif concentré. Mesurer les délégués et entités coordonnées, pas seulement les adresses. Publier la part des principaux délégués, la distribution de participation et les dépendances aux fondations, dépositaires, teneurs de marché et représentants.
Règles faibles de proposition et de quorum. Comparer les seuils au pouvoir actif, à l’offre empruntable et à l’exposition de la trésorerie. Distinguer les exigences des paramètres courants et des mises à niveau ou transferts à fort impact.
Snapshots non sûrs. Utiliser des points historiques immuables et une horloge commune au jeton et au gouverneur. Laisser un délai suffisant avant le snapshot pour rendre visibles accumulations ou délégations anormales.
Vote tardif ou surprise. Envisager une prolongation minimale si le quorum est atteint près de la clôture et surveiller les fortes variations de délégation pendant tout le cycle.
Charges opaques. Publier les appels décodés et des simulations indépendantes. Séparer les actions risquées sans lien afin qu’un élément bénin ne masque pas un changement d’administrateur ou un transfert.
Délai d’exécution insuffisant. Adapter le timelock à l’impact et publier les opérations en file. Le délai doit permettre examen, alertes, annulation ou pause et une sortie crédible des utilisateurs.
Rôles d’urgence excessifs. Limiter les gardiens par fonction, valeur, durée et norme d’examen. Publier membres, seuils, rotation, preuves requises et procédures de révocation et de reprise.
Voies de mise à niveau non examinées. Suivre administrateurs de proxy, balises, initialiseurs, déploiements métamorphiques et contrats actualisables après réception de l’autorité.
Risque d’exécution inter-chaînes. Authentifier gouverneur et message sources, empêcher le rejeu, limiter les fonctions cibles, ajouter un délai local aux appels critiques et définir le comportement en cas de panne ou suspension du pont.
Surveillance insuffisante. Alerter sur création de propositions, concentration des voix, changements de quorum, mise en file et annulation, changements d’état décodés, mises à niveau, attributions de rôles, autorisations et sorties de trésorerie.
Réponse aux incidents défaillante. Répéter propositions malveillantes, perte de signataires, compromission du frontal, panne du pont et pauses erronées. Consigner qui décide, communique, signe, vérifie et rétablit le service en sécurité.
Valeur à risque illimitée. Limiter transferts unitaires et cumulés, portée des mises à niveau, émission, changements de garantie et autorisations. Un vote adopté ne doit pas accorder automatiquement une autorité illimitée.

Le résultat doit être un registre de contrôle reproductible : chaque action privilégiée, son contrôleur, les voix ou clés requises, le premier instant d’exécution, la voie d’annulation, la source de surveillance et la valeur maximale accessible. Le recalculer après mises à niveau, distributions de jetons, changements de délégation, migrations de ponts ou fortes variations de liquidité et de participation.

Idées reçues

« L’attaquant a besoin de 51% de l’offre totale. » La plupart des systèmes dépendent des voix déléguées ou participantes, du quorum et de la règle d’adoption. Le contrôle décisif peut coûter bien moins que la moitié de l’offre.
« Les snapshots éliminent les attaques de gouvernance. » Ils empêchent certains réemplois ou emprunts de dernière minute, pas les emprunts antérieurs, achats, concentrations de délégation, pots-de-vin ou clés privilégiées compromises.
« Un vote adopté en chaîne prouve la légitimité. » Il prouve seulement que les conditions du code sont remplies, pas que description et charge concordent ni que le résultat est sûr, équitable et conforme aux engagements publics.
« Un timelock plus long est toujours plus sûr. » Il n’est utile que s’il permet surveillance, analyse, annulation ou pause, communication et sortie. Un délai excessif peut gêner une maintenance urgente.
« Un conseil de sécurité résout le risque. » Il peut accélérer la réponse, mais crée une autre voie de contrôle. Autorité, responsabilité, révocation et défaillances doivent entrer dans le même modèle de menace.

Sujets associés

Sources

Governance - OpenZeppelin Documentation (consulté le 2026-08-20)
ERC-5805: Voting with delegation - Ethereum Improvement Proposals (consulté le 2026-08-20)
Compound v2 Governance - Compound Documentation (consulté le 2026-08-20)
Beanstalk Governance Exploit - Beanstalk Farms (consulté le 2026-08-20)