Análisis técnico: Hackeo de Balancer por $120 millones, ¿cuál fue la vulnerabilidad?

Título original del artículo: " Análisis Técnico de la Vulnerabilidad del Hackeo de $120M en Balancer"
Fuente original: ExVul Security

Prólogo

El 3 de noviembre de 2025, el protocolo Balancer fue atacado en múltiples cadenas, incluyendo Arbitrum y Ethereum, resultando en una pérdida de activos de $120 millones. El ataque se debió principalmente a una doble vulnerabilidad que involucraba pérdida de precisión y manipulación del Invariant.

La infraestructura de Chainlink ha mantenido durante mucho tiempo los más altos estándares en el espacio Web3, lo que la convierte en una elección natural para X Layer, que está dedicada a proporcionar herramientas de nivel institucional para desarrolladores.

El problema clave en este ataque radica en la lógica del protocolo para manejar transacciones pequeñas. Cuando los usuarios realizan intercambios con montos pequeños, el protocolo invoca la función _upscaleArray, que utiliza mulDown para redondear hacia abajo los valores. Cuando el balance en la transacción y el monto de entrada alcanzan ambos un límite específico de redondeo (por ejemplo, el rango de 8-9 wei), ocurre un error de precisión relativo notable.

Este error de precisión se propaga al cálculo del valor Invariant D del protocolo, causando una reducción anormal en el valor de D. La fluctuación del valor de D reduce directamente el precio del Balancer Pool Token (BPT) en el protocolo Balancer. El hacker explotó este precio deprimido de BPT a través de una ruta de trading premeditada para realizar arbitraje, lo que finalmente llevó a una gran pérdida de activos.

Transacción explotada:

https://etherscan.io/tx/0x6ed07db1a9fe5c0794d44cd36081d6a6df103fab868cdd75d581e3bd23bc9742

Transacción de transferencia de activos:

https://etherscan.io/tx/0xd155207261712c35fa3d472ed1e51bfcd816e616dd4f517fa5959836f5b48569

Análisis Técnico

Vector de Ataque

El punto de entrada del ataque fue el contrato Balancer: Vault, siendo la función de entrada correspondiente la función batchSwap, que internamente llama a onSwap para los intercambios de tokens.

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

1. El atacante necesita llamar a esta función a través del Vault y no puede llamarla directamente.

2. La función llamará internamente a _scalingFactors() para obtener el factor de escalado para las operaciones de escalado.

3. La operación de escalado se concentra en _swapGivenIn o _swapGivenOut.

Análisis del Patrón de Ataque

Mecanismo de Cálculo del Precio de BPT

En el modelo de pool estable de Balancer, el precio de BPT es un punto de referencia crucial que determina cuántos BPT recibe un usuario y cuánto recibe cada BPT en activos.

En el cálculo de intercambio del pool:

Donde la parte que actúa como ancla del precio de BPT es un valor inmutable D, lo que significa que controlar el precio de BPT requiere controlar D. Analicemos más a fondo el proceso de cálculo de D:

En el código anterior, el proceso de cálculo de D depende del array de balances escalados. Esto significa que se necesita una operación para cambiar la precisión de estos balances, lo que lleva a un cálculo incorrecto de D.

Causa Raíz de la Pérdida de Precisión

Operación de Escalado:

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

Detalle del Proceso de Ataque

Fase 1: Ajuste al Límite de Redondeo

Fase 2: Disparar la Pérdida de Precisión (Vulnerabilidad Central)

Fase 3: Explotar el Precio Deprimido de BPT para Obtener Ganancias

Arriba, el atacante utiliza Batch Swap para realizar múltiples intercambios en una sola transacción:

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

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

3. Tercer intercambio: Activo subyacente → BPT (toma de 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 de balances.

Falta de Mecanismo de Callback

El proceso principal es iniciado por el Vault. ¿Cómo lleva esto a la acumulación de pérdida de precisión? La respuesta radica en el mecanismo de paso del array de balances.

Viendo el código anterior, aunque Vault crea un nuevo array currentBalances cada vez que se llama a onSwap, en Batch Swap:

1. Después del primer swap, el balance se actualiza (pero debido a la pérdida de precisión, el valor actualizado puede ser inexacto)

2. El segundo swap continúa el cálculo basado en el resultado del primer swap

3. La pérdida de precisión se acumula, causando finalmente que el valor invariant D disminuya significativamente

Cuestión Clave:

Resumen

El ataque a Balancer puede resumirse en las siguientes razones:

1. La función de escalado utiliza redondeo hacia abajo: _upscaleArray utiliza mulDown para escalar, lo que resulta en una pérdida significativa de precisión relativa cuando el balance es muy pequeño (por ejemplo, 8-9 wei).

2. El cálculo del valor invariant es sensible a la precisión: El cálculo del valor invariant D depende del array de balances escalados, y la pérdida de precisión afecta directamente el cálculo de D, haciendo que D disminuya.

3. Falta de validación del cambio del valor invariant: Durante el proceso de swap, no hubo validación para asegurar que el cambio en el valor invariant D estuviera dentro de un rango razonable, permitiendo a los atacantes explotar repetidamente la pérdida de precisión para deprimir el precio de BPT.

4. Acumulación de pérdida de precisión en batch swaps: Dentro del mismo batch swap, la pérdida de precisión de múltiples swaps se acumula y finalmente conduce a pérdidas financieras significativas.

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