Exploit de pool Balancer v2

En novembre 2025, Balancer v2 — l'un des automated market makers les plus anciens en DeFi — a été exploité pour environ 120 millions de dollars sur plusieurs stable pools et composable pools. L'attaque a enchaîné deux problèmes distincts : une vérification de contrôle d'accès manquante et une erreur d'arrondi dans l'arithmétique d'invariant du pool.

Ce qui s'est passé

L'exploit a ciblé les composable stable pools de Balancer v2. La vulnérabilité avait deux moitiés :

1. Une vérification de contrôle d'accès manquante permettait à un appelant d'invoquer une fonction sensible de mutation d'état de pool qui aurait dû être restreinte au propriétaire du pool.
2. Une erreur d'arrondi dans la logique de manipulation d'invariant permettait à l'attaquant de déplacer la valeur lastInvariant du pool vers un état que les mathématiques de l'AMM traitaient comme profitable pour eux.

En exploitant à répétition le biais d'arrondi sous des conditions contrôlées par l'attaquant, l'opérateur a pu extraire approximativement la part de frais du protocole du pool à chaque itération — composée sur de nombreuses transactions et de nombreux pools.

La perte s'est étendue à travers les pools Balancer et les protocoles construits par-dessus, y compris les wrappers d'actifs peggés et porteurs de rendement qui utilisaient Balancer pour la liquidité.

Conséquences

• La gouvernance Balancer a mis en pause les pools affectés.
• L'équipe a publié un post-mortem et a livré des correctifs pour v2 ; la v3 à venir avait déjà déplacé la maintenance d'invariant dans une abstraction différente moins susceptible à la même classe de bug.
• Certains protocoles en aval ont absorbé les pertes directement ; d'autres ont négocié des récupérations partielles avec l'attaquant.

Pourquoi c'est important

Balancer a démontré encore une fois — cinq ans après le début de l'ère DeFi-AMM — que les mathématiques d'invariant dans les AMMs en production restent un domaine pionnier. La direction d'arrondi, la troncature entière, et l'interaction entre les setters d'état de pool et les readers d'invariant continuent d'être une classe de vulnérabilités fertile. Le schéma successeur (v3, et les conceptions similaires chez Uniswap et Curve) intègre explicitement la maintenance d'invariant dans des bibliothèques durcies et gelées par audit plutôt que dans du code par pool.