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

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

Prólogo

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

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 al manejar transacciones de bajo valor. Cuando los usuarios realizan intercambios de pequeñas cantidades, el protocolo llama a la función _upscaleArray, la cual utiliza mulDown para redondear hacia abajo los valores. Si el saldo y el importe 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 notable.

El error de precisión se transmite al proceso de cálculo del invariante D del protocolo, lo que provoca que el valor de D se reduzca anormalmente. La variación de D afecta directamente al precio del BPT (Balancer Pool Token) en el protocolo Balancer. Los hackers aprovecharon este precio de BPT artificialmente bajo para realizar arbitraje a través de rutas de transacción previamente diseñadas, lo que finalmente causó enormes pérdidas de activos.

Tx de explotación de la vulnerabilidad:

Tx de transferencia de activos:

Análisis técnico

Punto de entrada del ataque

El punto de entrada del ataque es el contrato Balancer: Vault, cuya función de entrada es 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 obtiene cada BPT.

En el cálculo de intercambios del pool:

La parte que actúa como referencia del precio de BPT es el invariante D, por lo que 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 requiere una operación que cambie la precisión de estos balances, provocando 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 pasar por _upscaleArray, si el saldo es muy pequeño (por ejemplo, 8-9 wei), el redondeo hacia abajo de mulDown provocará una pérdida de precisión significativa.

Detalle del proceso de ataque

Fase 1: Ajuste al límite de redondeo

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

Fase 3: Obtención de beneficios mediante el precio de BPT deprimido

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

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

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

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

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

Ausencia de mecanismo 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 el 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 invariante D se reduzca notablemente

Problema clave:

Resumen

El ataque a Balancer puede resumirse en las siguientes causas:

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 invariante es sensible a la precisión: El cálculo del invariante D depende del array balances escalado, por lo que 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 invariante: Durante el intercambio, no se verifica si la variación de D está dentro de un rango razonable, lo que permite que el atacante aproveche repetidamente la pérdida de precisión para deprimir 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, la pérdida de precisión y la falta de verificación, combinados con el diseño cuidadoso de las condiciones límite por parte del atacante, causaron esta pérdida.