Análisis técnico: Balancer fue hackeado por 120 millones de dólares, ¿dónde estuvo la falla?

Título original: «Análisis técnico de la vulnerabilidad de $120M robados en Balancer»
Fuente original: ExVul Security

Introducción

El 3 de noviembre de 2025, el protocolo Balancer fue atacado por hackers en varias blockchains como Arbitrum y Ethereum, lo que resultó en una pérdida de 120 millones de dólares en activos. El núcleo del ataque se debió a una doble vulnerabilidad: la pérdida de precisión y la manipulación del valor invariante (Invariant).

La infraestructura de Chainlink ha mantenido durante mucho tiempo los más altos estándares en el ámbito Web3, por lo que se ha convertido en la elección natural para que X Layer proporcione herramientas de nivel institucional a los desarrolladores.

El problema clave de este ataque radica en la lógica del protocolo para manejar transacciones de bajo monto. Cuando los usuarios realizan intercambios de pequeñas cantidades, el protocolo llama a la función _upscaleArray, que utiliza mulDown para redondear los valores hacia abajo. Si el saldo y el monto de entrada de la transacción se encuentran simultáneamente en un límite específico de redondeo (por ejemplo, en el rango de 8-9 wei), se produce un error relativo de precisión significativo.

El error de precisión se transmite al proceso de cálculo del valor invariante D del protocolo, lo que provoca que el valor D se reduzca anormalmente. La variación de D afecta directamente el precio del BPT (Balancer Pool Token) en el protocolo Balancer. El hacker aprovechó este precio de BPT artificialmente bajo para ejecutar una ruta de trading previamente diseñada y obtener arbitraje, lo que finalmente resultó en una gran pérdida de activos.

Transacción de explotación de la vulnerabilidad:

Transacción de transferencia de activos:

Análisis técnico

Punto de entrada del ataque

El punto de entrada del ataque es el contrato Balancer: Vault, y la función de entrada correspondiente es la función batchSwap, que internamente llama a onSwap para realizar el intercambio de tokens.

A partir de los parámetros y restricciones de la función, se pueden obtener varias informaciones:

1. El atacante debe llamar a esta función a través de Vault, no puede llamarla directamente.

2. Dentro de la función se llama a _scalingFactors() para obtener el factor de escala y realizar la operación de escalado.

3. Las operaciones de escalado se concentran en _swapGivenIn o _swapGivenOut.

Análisis del modo de ataque

Mecanismo de cálculo del precio de BPT

En el modelo de pool estable de Balancer, el precio de BPT es un referente importante, ya que determina cuántos BPT recibe el usuario y cuántos activos recibe cada BPT.

En el cálculo de intercambios del pool:

La parte que sirve como referencia del precio de BPT es el valor invariante D, es decir, para manipular el precio de BPT es necesario manipular D. Analicemos el proceso de cálculo de D:

En el código anterior, el cálculo de D depende del array balances escalado. Es decir, se necesita una operación que cambie la precisión de estos balances, lo que provoca un error en el cálculo de D.

Raíz de la pérdida de precisión

Operación de escalado:

Como se muestra arriba, al usar _upscaleArray, si el saldo es muy pequeño (por ejemplo, 8-9 wei), el redondeo hacia abajo de mulDown provoca una pérdida de precisión significativa.

Detalle del proceso de ataque

Fase 1: Ajuste al límite de redondeo

Fase 2: Disparar la pérdida de precisión (vulnerabilidad principal)

Fase 3: Obtener ganancias aprovechando el precio bajo de BPT

Como se muestra arriba, el atacante ejecuta múltiples intercambios en una sola transacción usando Batch Swap:

1. Primer intercambio: BPT → cbETH (ajuste de saldo)

2. Segundo intercambio: wstETH (8) → cbETH (disparar la pérdida de precisión)

3. Tercer intercambio: activo subyacente → BPT (obtener ganancias)

Todos estos intercambios ocurren en la misma transacción de batch swap, compartiendo el mismo estado de balances, pero cada intercambio llama a _upscaleArray para modificar el array balances.

Ausencia del mecanismo de Callback

El proceso principal es iniciado por Vault, ¿cómo se acumula la pérdida de precisión? La respuesta está en el mecanismo de transmisión del array balances.

Analizando el código anterior, aunque Vault crea un nuevo array currentBalances en cada llamada a onSwap, en Batch Swap:

1. Después del primer intercambio, el saldo se actualiza (pero debido a la pérdida de precisión, el valor actualizado puede no ser exacto)

2. El segundo intercambio se calcula en base al resultado del primero

3. La pérdida de precisión se acumula, lo que finalmente provoca que el valor invariante D se reduzca significativamente

Problema clave:

Resumen

El ataque a Balancer se puede resumir en los siguientes puntos:

1. La función de escalado utiliza redondeo hacia abajo: _upscaleArray utiliza mulDown para escalar, y cuando el saldo es muy bajo (por ejemplo, 8-9 wei), se produce una pérdida de precisión relativa significativa.

2. El cálculo del valor invariante es sensible a la precisión: el cálculo del valor invariante D depende del array balances escalado, y la pérdida de precisión se transmite directamente al cálculo de D, haciendo que D disminuya.

3. Falta de verificación de la variación del valor invariante: durante el intercambio, no se verifica si la variación del valor invariante D está dentro de un rango razonable, lo que permite que el atacante aproveche repetidamente la pérdida de precisión para bajar el precio de BPT.

4. Acumulación de pérdida de precisión en Batch Swap: en un mismo batch swap, la pérdida de precisión de múltiples intercambios se acumula, lo que finalmente se traduce en una gran pérdida financiera.

Estos dos problemas —pérdida de precisión y falta de verificación— combinados con el diseño cuidadoso de las condiciones límite por parte del atacante, provocaron esta pérdida.