~$36M Perdidos: Summer.fi, Bonzo Lend y Más | BlockSec Semanal

Durante la semana pasada (2026/07/06 - 2026/07/12), se identificaron un total de 3 incidentes de seguridad notables, que resultaron en aproximadamente $36.29M en pérdidas.

• Summer.fi: Seleccionado porque ilustra cómo, en protocolos de bóvedas de múltiples capas, un componente secundario incompletamente desactivado puede corromper silenciosamente los precios de participación en el nivel superior, destacando la importancia crítica de completar el proceso de desmantelamiento antes de que las posiciones deterioradas se vuelvan explotables.
• Bonzo Lend: Seleccionado porque demuestra cómo una falla sutil en la verificación BLS en la capa del oráculo puede eludir completamente la seguridad de las firmas, lo que lleva a raíces de precios falsificadas y riesgo sistémico para los protocolos que dependen del verificador afectado.

Destacado de la semana: Summer.fi

Este incidente se destaca porque ilustra cómo, en protocolos de bóvedas de múltiples capas, un componente secundario incompletamente desactivado puede corromper silenciosamente los precios de participación en el nivel superior. El patrón se aplica ampliamente a cualquier sistema que agregue valores de fuentes anidadas o externas sin verificar que cada contribuyente siga siendo saludable.

El 6 de julio de 2026, la bóveda FleetCommander de Summer.fi en Ethereum fue explotada por aproximadamente $6.04M [1][2]. La causa raíz fue que el FleetCommander de Summer.fi todavía contabilizaba un componente de estrategia (llamado Ark) que había sido limitado para su desactivación pero aún no eliminado del conjunto activo al calcular su totalAssets(). El atacante acumuló grandes cantidades de tokens vgUSDC obsoletos y sobrevaluados que el Ark todavía valoraba cerca de la par, luego los transfirió directamente al Ark para inflar el precio de participación del FleetCommander y los canjeó al precio inflado.

Contexto

Summer.fi es un agregador de rendimiento DeFi construido sobre una arquitectura de bóveda de bóvedas. Los usuarios depositan activos en una bóveda principal ERC-4626 llamada FleetCommander, que enruta los fondos a través de un conjunto de adaptadores de estrategia llamados Arks hacia varios protocolos subyacentes de préstamos y rendimiento. Los activos totales del FleetCommander se agregan a partir del valor autoinformado de cada Ark, y los usuarios pueden canjear sus participaciones en cualquier momento basándose en esta valoración agregada.

Una de las fuentes de rendimiento subyacentes es Morpho. El FleetCommander, a través de un Ark, deposita fondos en una bóveda Morpho y se valora a sí mismo por las participaciones que posee en esa bóveda. Cuando un usuario canjea participaciones de FleetCommander, si el buffer de efectivo de la bóveda principal es insuficiente, extrae fondos de las bóvedas subyacentes en orden ascendente:

El usuario canjea participaciones de FleetCommander
   | (1) Quemar las participaciones del usuario
   v
FleetCommander
   | (2) Pagar primero desde el buffer; luego extraer de los Arks
   v
Ark
   | (3) Para obtener efectivo, canjea sus propias participaciones en la bóveda subyacente
   v
Bóveda Morpho
     (4) Para pagar, retira de los mercados subyacentes

Cada Ark calcula su totalAssets() consultando su propio saldo de tokens en la bóveda subyacente y convirtiendo esas participaciones en activos. Dado que estas participaciones son tokens ERC-20 estándar, cualquiera puede transferir participaciones adicionales directamente al Ark sin pasar por el flujo de depósito del FleetCommander.

Análisis de vulnerabilidad

Los FleetCommanders afectados son la bóveda USDC de menor riesgo (0x98C4...cF17) y la bóveda USDC de mayor riesgo (0xE9cD...cB06). El Ark Silo Varlamore manipulado es 0x61d7...76c2.

Dos condiciones prepararon el terreno para la explotación:

1. Un activo obsoleto y sobrevaluado. Tras el colapso de Stream Finance en noviembre de 2025 [3] y la pérdida de más del 75% del valor de su token de rendimiento xUSD, la bóveda Silo "Varlamore USDC Growth", que tenía posiciones respaldadas por xUSD, se volvió en gran medida irrecuperable. Sin embargo, la contabilidad on-chain de la bóveda nunca reflejó esta pérdida: los tokens vgUSDC continuaron reportando un valor cercano a la par a través de convertToAssets(), incluso mientras el USDC subyacente permanecía bloqueado.

2. Un Ark parcialmente eliminado. El Ark que mantenía esta exposición deteriorada estaba siendo desactivado con su límite de depósito establecido en 0. Sin embargo, poner el límite en cero solo bloquea nuevos depósitos a través del FleetCommander. No elimina el Ark del cálculo de totalAssets().

Un Ark calcula su totalAssets() llamando a vault.balanceOf(address(this)) y luego a vault.convertToAssets(shares). Dado que esas participaciones son tokens ERC-20 transferibles, cualquiera puede transferir directamente más vgUSDC obsoletos y sobrevaluados al Ark, inflando su totalAssets() sin que se acuñen nuevas participaciones ni se agregue liquidez real retirable. Esta inflación se propaga hasta el precio de participación del FleetCommander.

Análisis del ataque

El siguiente análisis se basa en la transacción 0x0db528...43da12.

• Paso 1: Durante los tres meses anteriores, el atacante acumuló aproximadamente 19.08B de vgUSDC a través de múltiples carteras, luego las consolidó en el contrato de ataque poco antes del exploit.

• Paso 2: El atacante tomó un préstamo flash de 1,000,000 USDT de Morpho Blue, luego anidó un segundo préstamo flash de 65,419,171 USDC para financiar el ataque.

• Paso 3: El atacante llamó a forceDeallocate() en múltiples bóvedas Morpho V2, extrayendo 4,318,535 USDC de los mercados de Morpho Blue de vuelta a los saldos inactivos de las bóvedas. Esto garantizó que hubiera suficiente capital líquido disponible para pagar el canje inflado en un paso posterior.

• Paso 4: El atacante intercambió 20,000 USDT por aproximadamente 68,421 xUSD en Uniswap V4, luego intercambió ese xUSD por aproximadamente 476.27M vgUSDC en Balancer V3. Esto acumuló tokens obsoletos adicionales a un costo real mínimo.

• Paso 5: El atacante depositó 64,828,534 USDC en FleetCommander LVUSDC y recibió 60,787,156 participaciones.

• Paso 6: El atacante transfirió directamente aproximadamente 19.55B de participaciones vgUSDC al Ark vgUSDC. Dado que el totalAssets() del Ark contabiliza todas las participaciones que posee independientemente de cómo llegaron, esto infló el valor reportado del Ark e influyó correspondientemente en el totalAssets() del FleetCommander.

• Paso 7: El atacante canjeó 60,766,209 participaciones de FleetCommander por 70,959,584 USDC, obteniendo ganancias por la diferencia entre el precio de participación inflado y el depósito original.

• Paso 8: Dentro de la misma transacción atómica, el atacante aplicó una inflación similar al FleetCommander USDC de mayor riesgo. La parte de mayor riesgo utilizó participaciones de Term donadas al Ark Term de mayor riesgo en lugar de vgUSDC, pero el mecanismo subyacente fue el mismo: inflar totalAssets() mediante donación, luego canjear al precio inflado. La ganancia combinada de ambas bóvedas fue de aproximadamente $6.04M.

Conclusión

Este fue un ataque de inflación de precios de participación causado por un fallo operativo más que por un error en el código. Un Ark Silo deteriorado por el colapso de Stream Finance todavía se contabilizaba en el totalAssets() del FleetCommander mientras estaba siendo desactivado [2]. El atacante donó vgUSDC acumulado de forma barata pero obsoleto y sobrevaluado a este Ark, infló el precio de participación y canjeó más de lo depositado a expensas de otros depositantes.

Poner en cero un límite de depósito no desactiva un Ark. Para los sistemas de bóvedas de múltiples capas, totalAssets() debe excluir las posiciones retiradas, y las participaciones deben valorarse según el valor realizable en lugar de cotizaciones obsoletas on-chain. Cualquier componente que esté siendo desactivado debe eliminarse completamente de la valoración agregada antes de que pueda servir como vector de inflación.

Referencias

• [1] Alerta de Phalcon en X
• [2] Resumen de la llamada comunitaria de Summer.fi
• [3] Stream Finance enfrenta una pérdida de $93 millones (CoinDesk)

Más incidentes de esta semana

Bonzo Lend

El 11 de julio de 2026, Bonzo Lend, un protocolo de préstamos en Hedera, sufrió una pérdida de aproximadamente $9.05M [1] después de que un atacante enviara una actualización de oráculo falsificada a Supra, el proveedor externo de feeds de precios del protocolo, para el feed de precios de SAUCE. El verificador del oráculo aceptó una prueba de firma cero y escribió un precio SAUCE/WHBAR inflado on-chain. Bonzo Lend luego leyó el feed manipulado y permitió al atacante tomar prestado muchos más activos de los que valía el colateral de SAUCE publicado.

Contexto

Bonzo Lend es un protocolo de préstamos en Hedera. Su contabilidad de mercado depende de feeds de precios externos, incluido Supra, una red de oráculos de terceros, para activos del ecosistema como SAUCE. Bonzo Lend no autentica por sí mismo cada firma del comité del oráculo; lee el último valor ya almacenado en el feed on-chain del oráculo y usa ese valor al calcular el valor del colateral y la capacidad de endeudamiento.

La ruta de actualización del oráculo pull de Supra verifica una raíz enviada antes de escribir los datos del feed en el almacenamiento. En la ruta de código relevante, verifyOracleProofV2() itera a través de los datos del oráculo enviados, llama a requireRootVerified() para las raíces que no están ya en caché en merkleSet, verifica las hojas de Merkle y luego escribe rondas de feed más recientes a través de packData().

if (merkleSet.contains(oracle.data[i].root)) {
    continue;
}
requireRootVerified(oracle.data[i].root, oracle.data[i].sigs, oracle.data[i].committee_id);
if (!merkleSet.set(oracle.data[i].root)) {
    revert RootIsZero();
}

La seguridad de la actualización del feed depende de que requireRootVerified() rechace las raíces que no estén genuinamente firmadas por el comité del oráculo configurado.

Análisis de vulnerabilidad

El contrato con errores es el verificador del oráculo Supra (0.0.4323006).

La causa raíz fue una ruta de verificación BLS inválida en el verificador del oráculo Supra ascendente. La transacción de exploit envió una actualización de precio para el par 425 (SAUCE/WHBAR) con ID de comité 2 y un valor de firma puesto a cero [0, 0].

Para una verificación BLS normal, el verificador debería validar que la firma y la clave pública sean distintas de cero, estén en la curva y en el subgrupo correcto antes de llamar al precompilado de emparejamiento. El verificador vulnerable construyó una verificación de emparejamiento a partir de un punto de firma cero y un punto de clave pública de comité cero. El precompilado de emparejamiento de Hedera devolvió true porque el producto de emparejamiento para puntos identidad es matemáticamente válido, no porque existiera una firma real del comité.

El verificador debe comprobar la validez de las entradas; el precompilado solo verifica la ecuación de emparejamiento. Al omitir el rechazo del punto cero antes del emparejamiento, el oráculo aceptó una raíz falsificada y permitió que los datos de precio manipulados pasaran al almacenamiento.

function requireHashVerified_V2(
    bytes32 _message,
    uint256[2] calldata _signature,
    uint256 committee_id
) public view {
    bool callSuccess;
    bool checkSuccess;
    (checkSuccess, callSuccess) = BLS.verifySingle(
        _signature,
        committee_public_key[committee_id],
        BLS.hashToPoint(domain, abi.encode(_message)),
        blsPrecompileGasCost
    );
    if (!callSuccess) {
        revert BLSInvalidPublicKeyorSignaturePoints();
    }
    if (!checkSuccess) {
        revert BLSIncorrectInputMessaage();
    }
}

Análisis del ataque

El siguiente análisis se basa en la transacción 0.0.995584-1783731093-686041919.

• Paso 1: El atacante depositó 250 SAUCE en Bonzo Lend como colateral.

• Paso 2: El atacante envió la actualización maliciosa del oráculo al contrato de oráculo pull de Supra. La actualización estableció el precio de SAUCE en un valor extremadamente inflado utilizando la prueba de firma BLS puesta a cero descrita anteriormente.

• Paso 3: verifyOracleProofV2() aceptó la raíz enviada después de que requireRootVerified() retornara exitosamente. La función verificó los datos de la hoja de Merkle y llamó a packData() para la ronda de feed más reciente, haciendo que el valor manipulado de SAUCE/WHBAR se convirtiera en el último valor del oráculo almacenado.

• Paso 4: Bonzo Lend leyó el último precio de SAUCE del oráculo. Dado que el valor del feed almacenado ya estaba inflado, el protocolo calculó que el colateral de 250 SAUCE del atacante valía mucho más que su valor de mercado.

• Paso 5: El atacante tomó prestados aproximadamente 6.6M USDC y 34.5M WHBAR contra el valor del colateral inflado. El precio anormal permaneció activo hasta que una actualización legítima posterior del oráculo restauró SAUCE a su rango normal.

Conclusión

Este incidente fue un fallo de verificación del oráculo, no un error de contabilidad del pool de préstamos. El atacante no necesitó manipular el mercado de SAUCE ni eludir las comprobaciones internas de colateral de Bonzo Lend. El precio falsificado fue aceptado por el verificador del oráculo Supra ascendente, escrito en el feed y consumido por Bonzo Lend a través de su ruta normal de lectura de precios.

Los protocolos que consumen feeds externos heredan los supuestos de seguridad de toda la ruta de verificación del oráculo. Para las actualizaciones de oráculos basadas en BLS, los puntos cero deben rechazarse antes de llamar al precompilado de emparejamiento. La validación de entradas en la capa criptográfica no es opcional; la validez matemática de una ecuación de emparejamiento no implica la autenticidad de la firma subyacente.

Referencias

• [1] Informe de incidente de Bonzo Finance

• Comienza con Phalcon Security

  Detecta cada amenaza, alerta sobre lo que importa y bloquea ataques.

  Pruébalo gratis ahora