[Long thread en anglais] Analyse approfondie de l’attaque contre Balancer V2 : mécanisme de la faille, étapes de l’attaque et leçons à retenir

Chainfeeds Guide :

L'attaquant a intentionnellement défini des paramètres, y compris le nombre d'itérations et le montant d'entrée, afin de maximiser l'effet de la perte de précision.

Source de l'article :

Auteur de l'article :

BlockSec

Opinion :

BlockSec : Le 3 novembre 2025, le Composable Stable Pool de Balancer V2, ainsi que plusieurs projets on-chain basés sur son fork, ont subi une attaque coordonnée cross-chain, entraînant une perte totale de plus de 125 millions de dollars. BlockSec a émis une alerte dès la première heure, puis publié une analyse préliminaire. Il s'agit d'une attaque hautement complexe. Notre enquête montre que la cause fondamentale provient d'une perte de précision dans le calcul de l'invariant, qui a permis de déclencher une manipulation de prix via cette perte de précision, affectant ainsi le prix du BPT (Balancer Pool Token). L'attaquant a profité d'une opération batchSwap unique pour tirer profit d'un pool stable spécifique. Le composant affecté est le Composable Stable Pool de Balancer V2. Ce type de pool est conçu pour des actifs censés maintenir un ratio d'échange proche de 1:1, permettant des transactions importantes avec un slippage minimal, augmentant considérablement l'efficacité du capital pour des actifs similaires ou corrélés. Chaque pool possède son propre BPT, dont le prix peut être approximativement exprimé comme suit : Prix du BPT = D / totalSupply, où D est l'invariant dans la mathématique stable, représentant la valeur totale virtuelle du pool. D'après la formule, si D est mathématiquement réduit (même si les fonds réels ne sont pas perdus), le prix du BPT apparaîtra plus bas. Balancer V2 propose la fonction batchSwap(), permettant des swaps multi-sauts dans le Vault, avec deux modes dans SwapRequest : GIVEN_IN et GIVEN_OUT. En mode GIVEN_OUT, l'appelant spécifie le montant de sortie souhaité, et le pool calcule le montant d'entrée requis. Dans un pool Stable, lors du calcul du montant d'entrée amountIn, il faut résoudre une équation polynomiale basée sur la formule de l'invariant, ces calculs étant uniformément soumis à des opérations d'Upscaling et de Downscaling. Théoriquement, ces deux opérations sont opposées, mais dans la pratique, leur implémentation diffère dans la direction de l'arrondi : l'upscaling utilise uniquement l'arrondi inférieur (mulDown), tandis que le downscaling peut arrondir vers le haut ou vers le bas (divUp / divDown). Cette incohérence a laissé une faille exploitable. La racine du bug réside dans le fait que, dans BaseGeneralPool._swapGivenOut(), l'upscaling de swapRequest.amount utilise un arrondi inférieur. La valeur ainsi arrondie est utilisée comme amountOut pour l'entrée de _onSwapGivenOut(), ce qui fait que le amountIn calculé est inférieur au besoin réel, violant ainsi le principe selon lequel l'arrondi devrait toujours favoriser le protocole. Pour des pools comme (wstETH / rETH / cbETH), l'attaquant peut échanger une quantité moindre d'un actif contre une quantité supérieure d'un autre, réduisant l'invariant D et donc le prix du BPT. L'attaquant a exécuté une attaque en deux phases. La première phase réalise la logique principale de l'attaque en une seule transaction, sans profit immédiat ; la seconde phase consiste à retirer le profit via une transaction séparée. La première phase se divise en deux étapes : calcul des paramètres et batch swap. Prenons l'exemple d'une transaction d'attaque sur la chaîne Arbitrum (TX : 0x7da32e…55773), l'attaquant commence par récupérer les paramètres du pool, y compris les scaling factors, A (coefficient d'amplification), le taux du BPT, les frais de swap, etc., puis calcule trickAmt et simule via un contrat auxiliaire déployé. L'attaquant combine calcul hors chaîne et simulation on-chain pour ajuster précisément les paramètres du swap suivant, y compris le nombre d'itérations et les valeurs d'entrée/sortie à chaque fois. L'itération comprend trois swaps : dans la première étape, la quantité de token cible est poussée à trickAmt + 1 ; la seconde étape continue à swapper le token cible, déclenchant alors l'arrondi inférieur de _upscale() ; la troisième étape effectue un swap inverse, ramenant le solde du pool à une valeur tronquée à deux décimales inférieures, puis l'échange à nouveau. Par exemple, 324 816 → 320 000. Dans certains cas, la résolution mathématique StableSwap utilisant la méthode de Newton–Raphson échoue, l'attaquant prévoit alors deux fallback, réessayant avec 9/10 de la valeur initiale. Après l'attaque, Balancer, en raison de mécanismes partiellement impossibles à suspendre, a vu l'impact de l'attaque amplifié, suivi de copies et d'attaques similaires sur plusieurs chaînes, pour une perte totale dépassant 125 millions de dollars. Cet incident met en lumière quatre problèmes clés pour les protocoles décentralisés : mécanismes d'arrondi incohérents, évolution constante des techniques d'attaque, incapacité à suspendre le protocole amplifiant les pertes, absence de surveillance en temps réel des états d'initialisation et d'exploitation. L'upscaling n'autorise que l'arrondi inférieur, alors que le downscaling autorise l'arrondi dans les deux sens ; cette asymétrie, sous des paramètres extrêmes, s'accumule en une perte de précision exploitable. L'arrondi, censé toujours favoriser le protocole, nuit ici à ses intérêts. L'attaquant a utilisé une méthode en deux phases : la première exécute l'attaque sans profit apparent, la seconde retire les fonds, contournant les modèles de surveillance on-chain. Chaque étape combine simulation off-chain et on-chain, le contrat auxiliaire réutilisant même l'implémentation StableMath de Balancer, avec des messages d'erreur identiques. Après l'attaque, d'autres chaînes et de nombreux projets forkés ont été affectés, prouvant que tant que la logique mathématique stable et d'arrondi est identique, la faille peut se propager à travers l'écosystème. Cet événement démontre que les protocoles DeFi nécessitent des calculs mathématiques de plus grande précision, une vérification d'arrondi plus stricte, des mécanismes de simulation anti-paths suspects, ainsi qu'une capacité d'arrêt d'urgence en cas d'anomalie. [Texte original en anglais]