~$36M Perdidos: Summer.fi, Bonzo Lend e Mais | BlockSec Semanal

Durante a semana passada (2026/07/06 - 2026/07/12), um total de 3 incidentes de segurança notáveis foram identificados, resultando em aproximadamente $36,29M em perdas.

• Summer.fi: Selecionado porque ilustra como, em protocolos de vault em múltiplas camadas, um componente downstream incompletamente desativado pode corromper silenciosamente os preços de cotas no nível superior, destacando a importância crítica de concluir o processo de descomissionamento antes que posições comprometidas se tornem exploráveis.
• Bonzo Lend: Selecionado porque demonstra como uma falha sutil na verificação BLS na camada de oráculo pode contornar completamente a segurança de assinatura, levando a raízes de preços forjadas e risco sistêmico para protocolos dependentes do verificador afetado.

Destaque da Semana: Summer.fi

Este incidente é destacado porque ilustra como, em protocolos de vault em múltiplas camadas, um componente downstream incompletamente desativado pode corromper silenciosamente os preços de cotas no nível superior. O padrão se aplica amplamente a qualquer sistema que agrega valores de fontes aninhadas ou externas sem verificar se cada contribuinte ainda está saudável.

Em 6 de julho de 2026, o vault FleetCommander da Summer.fi na Ethereum foi explorado por aproximadamente $6,04M [1][2]. A causa raiz foi que o FleetCommander da Summer.fi ainda contabilizava um componente de estratégia (chamado de Ark) que havia sido limitado para desativação, mas ainda não havia sido removido do conjunto ativo ao calcular seu totalAssets(). O atacante acumulou grandes quantidades de tokens vgUSDC obsoletos e supervalorizados que o Ark ainda precificava próximo ao par, e então os transferiu diretamente para o Ark a fim de inflar o preço de cota do FleetCommander e resgatou pelo preço inflado.

Contexto

Summer.fi é um agregador de rendimento DeFi construído sobre uma arquitetura de vault de vaults. Os usuários depositam ativos em um vault pai ERC-4626 chamado FleetCommander, que roteia fundos por meio de um conjunto de adaptadores de estratégia chamados Arks para vários protocolos de empréstimo e rendimento subjacentes. O total de ativos do FleetCommander é agregado a partir do valor autodeclarado de cada Ark, e os usuários podem resgatar suas cotas a qualquer momento com base nessa avaliação agregada.

Uma das fontes de rendimento subjacentes é o Morpho. O FleetCommander, por meio de um Ark, deposita fundos em um Vault Morpho e se valoriza pelas cotas que detém nesse vault. Quando um usuário resgata cotas do FleetCommander, se o buffer de caixa do vault pai for insuficiente, ele puxa fundos da pilha dos vaults subjacentes:

Usuário resgata cotas do FleetCommander
   | (1) Queima as cotas do usuário
   v
FleetCommander
   | (2) Paga primeiro do buffer; depois puxa dos Arks
   v
Ark
   | (3) Para levantar caixa, resgata suas próprias cotas no vault subjacente
   v
Vault Morpho
     (4) Para pagar, retira dos mercados subjacentes

Cada Ark calcula seu totalAssets() consultando seu próprio saldo de tokens no vault subjacente e convertendo essas cotas em ativos. Como essas cotas são tokens ERC-20 padrão, qualquer pessoa pode transferir cotas adicionais diretamente para o Ark sem passar pelo fluxo de depósito do FleetCommander.

Análise de Vulnerabilidade

Os FleetCommanders afetados são o vault LowerRisk USDC (0x98C4...cF17) e o vault HigherRisk USDC (0xE9cD...cB06). O Ark Silo Varlamore manipulado é 0x61d7...76c2.

Duas condições prepararam o terreno para a exploração:

1. Um ativo obsoleto e supervalorizado. Após o colapso da Stream Finance em novembro de 2025 [3] e seu token de rendimento xUSD perder mais de 75% do seu valor, o vault Silo "Varlamore USDC Growth", que detinha posições lastreadas em xUSD, tornou-se amplamente irrecuperável. No entanto, a contabilidade on-chain do vault nunca refletiu essa perda: os tokens vgUSDC continuaram a reportar um valor próximo ao par por meio de convertToAssets(), mesmo com o USDC subjacente permanecendo bloqueado.

2. Um Ark parcialmente removido. O Ark que detinha essa exposição comprometida estava sendo desativado com seu limite de depósito definido como 0. No entanto, zerar o limite apenas bloqueia novos depósitos pelo FleetCommander. Não remove o Ark do cálculo de totalAssets().

Um Ark calcula seu totalAssets() chamando vault.balanceOf(address(this)) e depois vault.convertToAssets(shares). Como essas cotas são tokens ERC-20 transferíveis, qualquer pessoa pode transferir diretamente mais vgUSDC obsoleto e supervalorizado para o Ark, inflando seu totalAssets() sem que novas cotas sejam emitidas e sem que nenhuma liquidez real resgatável seja adicionada. Essa inflação se propaga até o preço de cota do FleetCommander.

Análise do Ataque

A análise a seguir é baseada na transação 0x0db528...43da12.

• Passo 1: Nos três meses anteriores, o atacante acumulou aproximadamente 19,08B de vgUSDC por meio de múltiplas carteiras, depois os consolidou no contrato de ataque pouco antes do exploit.

• Passo 2: O atacante tomou um empréstimo relâmpago de 1.000.000 USDT do Morpho Blue, depois aninhou um segundo empréstimo relâmpago de 65.419.171 USDC para financiar o ataque.

• Passo 3: O atacante chamou forceDeallocate() em múltiplos vaults Morpho V2, puxando 4.318.535 USDC dos mercados Morpho Blue de volta para os saldos ociosos dos vaults. Isso garantiu que capital líquido suficiente estivesse disponível para pagar o resgate inflado em uma etapa posterior.

• Passo 4: O atacante trocou 20.000 USDT por aproximadamente 68.421 xUSD na Uniswap V4, depois trocou esse xUSD por aproximadamente 476,27M de vgUSDC na Balancer V3. Isso acumulou tokens obsoletos adicionais a um custo real mínimo.

• Passo 5: O atacante depositou 64.828.534 USDC no FleetCommander LVUSDC e recebeu 60.787.156 cotas.

• Passo 6: O atacante transferiu diretamente aproximadamente 19,55B de cotas vgUSDC para o Ark vgUSDC. Como o totalAssets() do Ark contabiliza todas as cotas que detém independentemente de como chegaram, isso inflou o valor reportado pelo Ark e correspondentemente inflou o totalAssets() do FleetCommander.

• Passo 7: O atacante resgatou 60.766.209 cotas do FleetCommander por 70.959.584 USDC, lucrando com a diferença entre o preço de cota inflado e o depósito original.

• Passo 8: Dentro da mesma transação atômica, o atacante aplicou uma inflação semelhante ao FleetCommander HigherRisk USDC. A etapa HigherRisk utilizou cotas Term doadas ao Ark Term HigherRisk em vez de vgUSDC, mas o mecanismo subjacente foi o mesmo: inflar totalAssets() via doação e depois resgatar pelo preço inflado. O lucro combinado em ambos os vaults foi de aproximadamente $6,04M.

Conclusão

Este foi um ataque de inflação de preço de cota causado por uma falha operacional, e não por um bug de código. Um Ark Silo comprometido pelo colapso da Stream Finance ainda estava sendo contabilizado no totalAssets() do FleetCommander durante o processo de desativação [2]. O atacante doou vgUSDC acumulado a baixo custo, porém obsoleto e supervalorizado, neste Ark, inflou o preço de cota e resgatou mais do que depositou às custas dos demais depositantes.

Zerar um limite de depósito não desativa um Ark. Para sistemas de vault em múltiplas camadas, totalAssets() deve excluir posições desativadas, e as participações devem ser precificadas pelo valor realizável, e não por cotações obsoletas on-chain. Qualquer componente em processo de desativação deve ser completamente removido da avaliação agregada antes que possa servir como vetor de inflação.

Referências

• [1] Alerta Phalcon no X
• [2] Resumo da Chamada Comunitária Summer.fi
• [3] Stream Finance Enfrenta Perda de $93 Milhões (CoinDesk)

Mais Incidentes desta Semana

Bonzo Lend

Em 11 de julho de 2026, o Bonzo Lend, um protocolo de empréstimo na Hedera, sofreu uma perda de aproximadamente $9,05M [1] após um atacante submeter uma atualização forjada de oráculo ao Supra, provedor terceirizado de feed de preços do protocolo, para o feed de preços do SAUCE. O verificador do oráculo aceitou uma prova com assinatura zerada e gravou on-chain um preço inflado de SAUCE/WHBAR. O Bonzo Lend então leu o feed manipulado e permitiu que o atacante tomasse emprestado muito mais ativos do que o valor real da garantia em SAUCE depositada.

Contexto

Bonzo Lend é um protocolo de empréstimo na Hedera. Sua contabilidade de mercado depende de feeds de preços externos, incluindo o Supra, uma rede de oráculos terceirizada, para ativos do ecossistema como SAUCE. O Bonzo Lend não autentica cada assinatura do comitê de oráculos por conta própria; ele lê o valor mais recente já armazenado no feed on-chain do oráculo e utiliza esse valor ao calcular o valor da garantia e a capacidade de empréstimo.

O caminho de atualização do oráculo pull do Supra verifica uma raiz submetida antes de gravar os dados do feed no armazenamento. No caminho de código relevante, verifyOracleProofV2() itera pelos dados do oráculo submetidos, chama requireRootVerified() para raízes ainda não armazenadas em cache em merkleSet, verifica as folhas Merkle e depois grava rounds de feed mais recentes por meio 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();
}

A segurança da atualização do feed depende de requireRootVerified() rejeitar raízes que não estejam genuinamente assinadas pelo comitê de oráculos configurado.

Análise de Vulnerabilidade

O contrato com defeito é o verificador do oráculo Supra (0.0.4323006).

A causa raiz foi um caminho de verificação BLS inválido no verificador de oráculo Supra upstream. A transação de exploit submeteu uma atualização de preço para o par 425 (SAUCE/WHBAR) com o ID de comitê 2 e um valor de assinatura zerado [0, 0].

Para uma verificação BLS normal, o verificador deve validar que a assinatura e a chave pública são não nulas, estão na curva e no subgrupo correto antes de chamar o precompilado de pareamento. O verificador vulnerável construiu uma verificação de pareamento a partir de um ponto de assinatura zero e um ponto de chave pública do comitê zero. O precompilado de pareamento da Hedera retornou true porque o produto de pareamento para pontos de identidade é matematicamente válido, não porque existia uma assinatura real do comitê.

O verificador deve checar a validade das entradas; o precompilado apenas verifica a equação de pareamento. Ao não rejeitar o ponto zero antes do pareamento, o oráculo aceitou uma raiz forjada e permitiu que os dados de preço manipulados fossem gravados no armazenamento.

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álise do Ataque

A análise a seguir é baseada na transação 0.0.995584-1783731093-686041919.

• Passo 1: O atacante depositou 250 SAUCE no Bonzo Lend como garantia.

• Passo 2: O atacante submeteu a atualização maliciosa do oráculo ao contrato pull-oracle do Supra. A atualização definiu o preço do SAUCE para um valor extremamente inflado enquanto utilizava a prova de assinatura BLS zerada descrita acima.

• Passo 3: verifyOracleProofV2() aceitou a raiz submetida após requireRootVerified() retornar com sucesso. A função verificou os dados da folha Merkle e chamou packData() para o round de feed mais recente, fazendo com que o valor manipulado de SAUCE/WHBAR se tornasse o valor mais recente armazenado no oráculo.

• Passo 4: O Bonzo Lend leu o preço mais recente do SAUCE a partir do oráculo. Como o valor armazenado no feed já estava inflado, o protocolo calculou que a garantia de 250 SAUCE do atacante valia muito mais do que seu valor de mercado.

• Passo 5: O atacante tomou emprestado aproximadamente 6,6M de USDC e 34,5M de WHBAR contra o valor inflado da garantia. O preço anormal permaneceu vigente até que uma atualização legítima posterior do oráculo restaurou o SAUCE ao seu intervalo normal.

Conclusão

Este incidente foi uma falha na verificação do oráculo, e não um bug na contabilidade do pool de empréstimo. O atacante não precisou manipular o mercado do SAUCE nem contornar as verificações internas de garantia do Bonzo Lend. O preço forjado foi aceito pelo verificador de oráculo Supra upstream, gravado no feed e consumido pelo Bonzo Lend por meio do seu caminho normal de leitura de preços.

Protocolos que consomem feeds externos herdam as premissas de segurança de todo o caminho de verificação do oráculo. Para atualizações de oráculos baseadas em BLS, pontos zero devem ser rejeitados antes que o precompilado de pareamento seja chamado. A validação de entradas na camada criptográfica não é opcional; a validade matemática de uma equação de pareamento não implica autenticidade da assinatura subjacente.

Referências

• [1] Relatório de Incidente da Bonzo Finance

• Comece a Usar o Phalcon Security

  Detecte cada ameaça, alerte o que importa e bloqueie ataques.

  Experimente gratuitamente