Analyse technique : Balancer a été piraté pour 120 millions de dollars, où se trouvait la faille ?

Titre original : « Analyse technique de la faille de $120M volés sur Balancer »
Source originale : ExVul Security

Préface

Le 3 novembre 2025, le protocole Balancer a été victime d'une attaque de hackers sur plusieurs blockchains telles qu'Arbitrum et Ethereum, entraînant une perte d'actifs de 120 millions de dollars. Le cœur de l'attaque réside dans une double faille liée à la perte de précision et à la manipulation de l'invariant.

L'infrastructure de Chainlink maintient depuis longtemps les standards les plus élevés dans le domaine Web3, ce qui en fait un choix naturel pour X Layer, qui s'efforce de fournir des outils de niveau institutionnel aux développeurs.

Le problème clé de cette attaque réside dans la logique de gestion des petites transactions par le protocole. Lorsqu'un utilisateur effectue un échange de faible montant, le protocole appelle la fonction _upscaleArray, qui utilise mulDown pour arrondir les valeurs à la baisse. Dès que le solde de la transaction et le montant d'entrée se situent simultanément à une certaine limite d'arrondi (par exemple dans la plage de 8-9 wei), une erreur de précision relative significative se produit.

L'erreur de précision se transmet au calcul de l'invariant D du protocole, ce qui conduit à une réduction anormale de la valeur D. Or, la variation de D entraîne directement une baisse du prix du BPT (Balancer Pool Token) dans le protocole Balancer. Le hacker exploite ce prix de BPT artificiellement bas pour réaliser un arbitrage via un chemin de transaction préalablement conçu, causant ainsi une perte massive d'actifs.

Transaction d'exploitation de la faille :

Transaction de transfert d'actifs :

Analyse technique

Point d'entrée de l'attaque

Le point d'entrée de l'attaque est le contrat Balancer: Vault, la fonction d'entrée correspondante étant la fonction batchSwap, qui appelle en interne onSwap pour l'échange de tokens.

À partir des paramètres et des restrictions de la fonction, on peut obtenir plusieurs informations :

1. L'attaquant doit appeler cette fonction via le Vault, il ne peut pas l'appeler directement.

2. La fonction appelle en interne _scalingFactors() pour obtenir le facteur d'échelle et effectuer l'opération de mise à l'échelle.

3. Les opérations de mise à l'échelle sont concentrées dans _swapGivenIn ou _swapGivenOut.

Analyse du mode d'attaque

Mécanisme de calcul du prix du BPT

Dans le modèle de pool stable de Balancer, le prix du BPT est une référence importante, déterminant combien de BPT l'utilisateur reçoit et combien d'actifs chaque BPT contient.

Dans le calcul des échanges du pool :

La partie servant de référence pour le prix du BPT est l'invariant D, ce qui signifie que pour manipuler le prix du BPT, il faut manipuler D. Analysons le processus de calcul de D :

Dans le code ci-dessus, le calcul de D dépend du tableau balances mis à l'échelle. Il faut donc une opération pour modifier la précision de ces balances, ce qui conduit à une erreur dans le calcul de D.

Origine de la perte de précision

Opération de mise à l'échelle :

Comme illustré ci-dessus, lors de l'appel à _upscaleArray, si le solde est très faible (par exemple 8-9 wei), l'arrondi à la baisse de mulDown entraîne une perte de précision significative.

Détail du processus d'attaque

Étape 1 : Ajustement à la limite d'arrondi

Étape 2 : Déclenchement de la perte de précision (faille principale)

Étape 3 : Profiter du prix du BPT artificiellement bas

Comme illustré ci-dessus, l'attaquant effectue plusieurs échanges dans une même transaction via le Batch Swap :

1. Premier échange : BPT → cbETH (ajustement du solde)

2. Deuxième échange : wstETH (8) → cbETH (déclenchement de la perte de précision)

3. Troisième échange : actif sous-jacent → BPT (profit)

Tous ces échanges se déroulent dans la même transaction batch swap, partageant le même état de solde, mais chaque échange appelle _upscaleArray pour modifier le tableau balances.

Absence de mécanisme de callback

Le processus principal est initié par le Vault, mais comment cela conduit-il à une accumulation de perte de précision ? La réponse réside dans le mécanisme de transmission du tableau balances.

En analysant le code ci-dessus, bien que le Vault crée un nouveau tableau currentBalances à chaque appel de onSwap, dans le Batch Swap :

1. Après le premier échange, le solde est mis à jour (mais en raison de la perte de précision, la valeur mise à jour peut être inexacte)

2. Le deuxième échange continue le calcul sur la base du résultat du premier

3. La perte de précision s'accumule, conduisant finalement à une réduction significative de l'invariant D

Problème clé :

Résumé

L'attaque sur Balancer peut être résumée par les points suivants :

1. La fonction de mise à l'échelle utilise un arrondi à la baisse : _upscaleArray utilise mulDown pour la mise à l'échelle. Lorsque le solde est très faible (par exemple 8-9 wei), cela entraîne une perte de précision relative significative.

2. Le calcul de l'invariant est sensible à la précision : Le calcul de l'invariant D dépend du tableau balances mis à l'échelle. Toute perte de précision se transmet directement au calcul de D, le faisant diminuer.

3. Absence de vérification de la variation de l'invariant : Lors des échanges, il n'y a pas de vérification pour s'assurer que la variation de l'invariant D reste dans une plage raisonnable, permettant ainsi à l'attaquant d'exploiter à plusieurs reprises la perte de précision pour faire baisser le prix du BPT.

4. Accumulation de la perte de précision dans le Batch Swap : Dans un même batch swap, la perte de précision de plusieurs échanges s'accumule, conduisant finalement à une perte financière considérable.

Ces deux problèmes — perte de précision et absence de vérification — combinés à la conception minutieuse des conditions limites par l'attaquant, ont conduit à cette perte.