Você não comprou rsETH, mas seu WETH foi congelado.

Introdução

Pontos principais:

• Entre 13 e 19 de abril de 2026, foram detectados quatro incidentes de ataque envolvendo várias blockchains, incluindo Ethereum, Unichain, Arbitrum e NEAR, com uma perda total estimada de aproximadamente US$ 310 milhões.

• Os vetores de ataque incluem envenenamento de infraestrutura RPC direcionada ao LayerZero DVN, falsificação de provas MMR, abuso de inteiros com sinal no fundo de seguro, e exploração de rotas de troca circular em protocolos de margem.

• O incidente do KelpDAO (US$ 290M) demonstra que a segurança das pontes cross-chain vai além do nível de contratos inteligentes, estendendo-se à infraestrutura de validação off-chain. Congelamentos em cascata de WETH em cinco blockchains e a conversão forçada de estado no Arbitrum revelam como a composabilidade pode ampliar pontos únicos de falha, além de questionar onde realmente residem os limites de confiança de sistemas “descentralizados”.

Na última semana (13/04/2026 - 19/04/2026), a BlockSec detectou e analisou quatro incidentes de ataque, com uma perda total estimada de cerca de US$ 310 milhões. A tabela a seguir resume esses eventos, e as próximas seções fornecerão análises detalhadas de cada um.

Tabela 1: Visão geral dos quatro incidentes detectados nesta semana

Destaques da semana: KelpDAO

Este incidente foi selecionado como destaque da semana devido ao seu novo vetor de ataque de infraestrutura (envenenamento de RPC direcionado ao DVN exclusivo, ao invés de vulnerabilidades em contratos inteligentes), ao impacto cascata em múltiplas blockchains causado por uma combinação de interoperabilidade DeFi, e às questões de governança levantadas pela execução de uma conversão de estado forçada no Arbitrum para recuperar fundos roubados.

Em 18 de abril de 2026, a ponte cross-chain rsETH LayerZero OFT do KelpDAO foi atacada, resultando em uma perda de aproximadamente US$ 290 milhões. A LayerZero Labs atribuiu o ataque a atores apoiados por estados, possivelmente o grupo Lazarus da Coreia do Norte [1]. A causa raiz foi a configuração DVN 1-de-1 do KelpDAO, que reduziu a validação de mensagens cross-chain a um ponto de falha único. Os atacantes envenenaram a infraestrutura RPC confiada pelo DVN da LayerZero Labs, forçando a assinatura de uma prova de mensagem cross-chain falsificada, o que levou à liberação de 116.500 rsETH na Ethereum, enquanto na cadeia de origem Unichain não houve evento de envio correspondente.

Contexto

LayerZero é um protocolo de mensagens cross-chain baseado em uma arquitetura modular de segurança. Sua integridade de mensagens é garantida por uma rede descentralizada de validadores (DVN), que é uma entidade off-chain responsável por verificar de forma independente se as mensagens enviadas na cadeia de origem realmente ocorreram, antes de permitir sua execução na cadeia de destino. Cada aplicação implantada na LayerZero configura seu próprio DVN, incluindo quais DVNs confiar, quantos devem participar e qual o limiar de consenso. Essa modularidade dá controle total ao aplicativo sobre o modelo de segurança, mas também implica responsabilidade total: configurações fracas não podem ser compensadas pelo protocolo.

O rsETH do KelpDAO, como OFT (Token Transferível de Toda a Cadeia), é implantado na LayerZero, conectando a Unichain (cadeia de origem) à rede principal Ethereum (destino). O padrão OFT permite que tokens sejam destruídos na cadeia de origem e liberados na cadeia de destino a partir de um estado de bloqueio, sendo a assinatura de mensagens de liberação a única autorização. O adaptador na Ethereum (0x85d456…e98ef3) é responsável por liberar rsETH ao receber uma mensagem validada e transmitida. O problema central é que o KelpDAO configurou essa rota como uma configuração DVN 1-de-1, nomeando a LayerZero Labs como o único validador. Isso significa que uma única prova de DVN pode autorizar a liberação de qualquer token, sem necessidade de confirmação de terceiros.

Para cumprir sua função de validação, o DVN da LayerZero Labs consulta múltiplos nós RPC, verificando se o evento de envio cross-chain realmente ocorreu na cadeia de origem. Esses nós incluem infraestrutura própria e provedores externos, e o DVN depende de suas respostas coletivas para assinar a prova. A integridade do processo assume que a maioria dos nós consultados retorna dados verdadeiros.

Análise de vulnerabilidade

A vulnerabilidade resulta de uma falha sistêmica na infraestrutura e na configuração, composta por três fraquezas acumuladas.

Primeiro, a configuração DVN 1-de-1 do KelpDAO elimina redundância na camada de validação. A recomendação do LayerZero exige múltiplos DVNs independentes, garantindo que a quebra de um único DVN não possa autorizar uma mensagem. Confiando apenas no DVN da LayerZero Labs, o KelpDAO garante que qualquer ataque bem-sucedido contra esse validador único seja suficiente para autorizar a liberação de tokens arbitrários.

Segundo, o mecanismo de failover do DVN roteia consultas de validação para qualquer nó RPC acessível. Essa abordagem assume que a indisponibilidade de um nó é uma falha acidental, não intencional. Contudo, ela cria uma condição na qual um atacante pode, sem precisar comprometer todas as fontes de dados, desativar nós saudáveis por DDoS e preparar nós envenenados como única fonte acessível, assumindo o controle completo dos dados recebidos pelo DVN.

Terceiro, a substituição do binário op-geth nos nós RPC requer acesso ao sistema operacional do servidor subjacente. O vetor de acesso inicial exato não foi divulgado, mas comprometer dois nós em clusters independentes sugere vulnerabilidades comuns na gestão de acesso a esses servidores.

Essas três fraquezas juntas formam uma cadeia de ataque: a primeira impede que DVNs independentes validem mensagens falsificadas, a segunda permite que um atacante controle os dados recebidos pelo DVN, e a terceira fornece o ponto de entrada para manipulação de dados. Nenhuma delas isoladamente é suficiente; juntas, possibilitam um ataque bem-sucedido.

Análise do ataque

A seguir, uma análise baseada na transação 0x1ae232…4222 e na declaração oficial da LayerZero Labs.

Passo 1: O atacante obtém a lista de nós RPC confiáveis do DVN da LayerZero Labs. Essa lista é uma informação de alto valor, pois conhecer os nós específicos permite planejar ações precisas, ao invés de ataques amplos à infraestrutura.

Passo 2: O atacante consegue permissões de escrita no sistema operacional de dois nós RPC e substitui o binário op-geth em execução por uma versão maliciosa. Esses nós estão em clusters independentes, indicando que o vetor de acesso inicial envolve dependências compartilhadas, como credenciais de implantação, pipelines de CI/CD ou engenharia social com operadores com múltiplos acessos. A LayerZero Labs não revelou detalhes específicos do vetor de acesso inicial. Essa etapa é pré-requisito para manipulação de dados subsequente.

Passo 3: O binário malicioso implementa uma lógica de resposta direcionada: responde com dados falsificados de transações apenas ao IP do DVN, enquanto fornece o estado real da blockchain para todas as outras requisições, incluindo infraestrutura de monitoramento, exploradores e serviços de varredura. Essa seletividade envenena os dados de forma invisível para os sistemas de observabilidade; de qualquer ponto externo, a cadeia de origem parece normal.

Passo 4: O consenso interno do DVN exige que os nós envenenados e não comprometidos cheguem a um acordo. Para resolver esse conflito, o atacante lança um DDoS nos nós saudáveis durante a janela de ataque (das 10h20 às 11h40, horário do Pacífico), acionando a lógica de failover do DVN, que passa a depender exclusivamente da infraestrutura envenenada. Essa etapa é essencial, pois, sem ela, os nós saudáveis retornariam dados verdadeiros contradizendo a resposta falsificada.

Passo 5: Com o DVN agora recebendo apenas dados controlados pelo atacante, uma mensagem falsa de cross-chain do LayerZero é considerada válida. O DVN prova um nonce 308 na cadeia Ethereum, enquanto na Unichain não há evento de saída correspondente (o nonce máximo reportado na origem é 307).

Passo 6: O adaptador rsETH na Ethereum, ao receber a mensagem validada, libera 116.500 rsETH para o endereço do atacante (0x8b1b6c…0d3b), que já tinha fundos depositados via Tornado Cash horas antes. Os tokens roubados são dispersos em várias carteiras, utilizados em posições de garantia na Aave, trocados por ETH e transferidos para Arbitrum para liquidação, com os lucros consolidados em endereços na Ethereum (0x5d3919…7ccc) e Arbitrum.

Passo 7: O binário malicioso, após executar a liberação, ativa um auto-desligamento, apagando seus próprios arquivos e logs locais. Isso dificulta a investigação posterior, demonstrando alta maturidade operacional do atacante.

Passo 8: O atacante tenta repetir o ataque na mesma rota para roubar mais 40.000 rsETH (~US$ 95 milhões), mas é impedido após o KelpDAO detectar anomalias e pausar todos os contratos relacionados na Ethereum e nas L2s [2].

Impacto mais amplo

O dano vai além da vulnerabilidade inicial na ponte cross-chain $290M : o atacante deposita cerca de 89.567 rsETH (~US$ 221 milhões) em vários mercados na Aave, emprestando WETH com LTV de 93% usando E-Mode [4]. Como a Aave não consegue distinguir na cadeia entre rsETH legítimo e tokens liberados por mensagem falsificada, os colaterais “tóxicos” são considerados válidos. Como consequência, os fundos de WETH ficam congelados, propagando-se de Ethereum para Arbitrum, Base, Mantle e Linea, afetando usuários que nunca interagiram com rsETH. Essa cascata de efeitos mostra como uma configuração fraca na ponte pode escalar para interrupções em múltiplas cadeias de DeFi, ampliando o alcance e o custo de uma falha única.

O evento também levanta questões sobre a operação descentralizada na prática. A LayerZero anunciou que seu DVN não mais assinará aplicações configuradas como 1-de-1, indicando que a dependência de configurações de aplicação fracas não pode ser resolvida apenas pelo protocolo.

No nível da cadeia, o Conselho de Segurança do Arbitrum executou uma ação emergencial, congelando 30.766 ETH sob controle do atacante no Arbitrum One. Segundo análise da BlockSec [1], essa ação foi uma conversão de estado forçada na cadeia: o Conselho temporariamente atualizou o contrato de inbox do Ethereum, injetou uma mensagem L1 não assinada simulando o endereço do atacante, e restaurou o contrato original, tudo sem assinatura do detentor [5].

Essa operação é uma ação legítima de emergência prevista na governança, executada de forma transparente após coordenação com autoridades. Contudo, também revela que o L2 foi projetado com uma capacidade de intervenção centralizada: teoricamente, qualquer ativo no Arbitrum One pode ser movido pelo Conselho usando esse mecanismo. Como cada camada do incidente demonstra, o modelo de confiança teórico difere da fronteira real de confiança, sendo esse o risco mais crítico.

Conclusão

Este incidente mostra que a segurança de pontes cross-chain não pode ser reduzida apenas à correção do protocolo. O protocolo LayerZero funciona conforme o esperado; as vulnerabilidades estão na camada operacional acima dele. A lição principal é que a infraestrutura de validação off-chain faz parte da fronteira de confiança, e sua segurança deve corresponder ao valor que protege.

Três medidas de mitigação, cada uma isoladamente, poderiam ter evitado esse incidente:

• Configuração com múltiplos DVNs: exigir consenso de vários DVNs independentes impede que um único DVN comprometido autorize a liberação de tokens, mesmo que seja completamente enganado.

• Seleção de RPC com capacidade de detecção de falhas: durante a janela de validação ativa, uma redução súbita nos nós acessíveis deve ser interpretada como sinal de ataque, não apenas como uma questão de disponibilidade. O DVN deve pausar ou alertar na redução de nós, ao invés de continuar operando com os remanescentes.

• Fortalecimento da infraestrutura RPC: a capacidade de substituir o binário em execução no nó RPC indica vulnerabilidades no controle de acesso ao servidor. A infraestrutura que fornece o estado real da cadeia deve ter limites de segurança equivalentes aos usados na assinatura do DVN.

De modo mais amplo, qualquer ponte cross-chain ou protocolo que dependa de provas off-chain deve auditar não apenas os contratos inteligentes, mas toda a cadeia de dados desde o evento na cadeia de origem até a execução na cadeia de destino. Quando bilhões de dólares dependem da infraestrutura RPC, a suposição de confiabilidade padrão não é mais válida.

Referências

[3] LayerZero Labs, “Declaração do Incidente KelpDAO”, 20 de abril de 2026. https://x.com/LayerZero_Core/status/2046081551574983137

[1] KelpDAO, “Contexto adicional do Incidente de 18 de abril”, 21 de abril de 2026. https://x.com/KelpDAO/status/2046332070277091807

[2] Arbitrum, “Ação de emergência do Conselho de Segurança”, 21 de abril de 2026. https://x.com/arbitrum/status/2046435443680346189

[3] LlamaRisk, “Relatório do Incidente rsETH”, 20 de abril de 2026. https://governance.aave.com/t/rseth-incident-report-april-20-2026/24580

[4] BlockSec, “Análise do mecanismo de congelamento do Conselho de Segurança do Arbitrum”, 21 de abril de 2026. https://x.com/Phalcon_xyz/status/2046467830498173088

Outros eventos desta semana

Hyperbridge

Em 13 de abril de 2026, o Hyperbridge, uma ponte de mensagens cross-chain baseada em Ethereum, foi atacado devido à falta de validação de entrada na lógica de prova MMR (Merkle Mountain Range), resultando em uma perda de aproximadamente US$ 242 mil. A função MerkleMountainRange.VerifyProof[5]( não força a verificação de que leaf_index < leafCount, permitindo que o atacante falsifique provas de cross-chain e execute operações privilegiadas, incluindo a cunhagem de 1 bilhão de tokens DOT.

) Contexto

Hyperbridge usa um modelo de validadores e agendadores na camada Ethereum para processar mensagens cross-chain. No lado Ethereum, o contrato HandlerV1 verifica a prova fornecida com base na root overlay armazenada. Se aceita, distribui a mensagem ao módulo de destino, como o TokenGateway.

O TokenGateway é um módulo de gerenciamento de ativos privilegiados. Além de funções padrão de ponte de ativos, suporta operações de governança, como criação, desativação e gerenciamento de administradores. Para ativos de ponte compatíveis com ERC6160Ext20, o administrador pode transferir a permissão de cunhagem via changeAdmin###(, e o novo administrador pode cunhar tokens arbitrários via mint)(.

Assim, a segurança do ativo depende da validação de prova em HandlerV1. Se uma mensagem falsificada passar na validação, o módulo interpretará a carga como uma instrução legítima de cross-chain.

) Análise da vulnerabilidade

O problema central está na lógica de validação de prova em HandlerV1 (0x6c84ed…6d64). A função handlePostRequests###( constrói uma estrutura MmrLeaf) com base na entrada do atacante e chama VerifyProof() para validar.

No entanto, VerifyProof() apenas verifica se root == CalculateRoot( com base na prova, folhas e tamanho do MMR, sem verificar se cada leaf.index < leafCount. Ao definir leafCount=1 e leaf_index=1, o atacante faz com que CalculateRoot)( ignore a carga falsificada, retornando uma root válida que corresponde ao estado histórico, mesmo que a mensagem não tenha sido realmente incluída na cadeia.

Isso quebra a ligação entre a mensagem e a prova, permitindo que qualquer carga seja aceita como válida, mesmo que nunca tenha sido registrada na cadeia de origem.

![])https://img-cdn.gateio.im/social/moments-b2403df3c2-75af16b47f-8b7abd-badf29(

Figura: trecho de código de VerifyProof com ausência de verificação de limite de leaf_index

) Análise do ataque

Baseado na transação 0x240aeb…1109 (.

Passo 1: O atacante, uma EOA 0xC513…F8E7, implanta contratos auxiliares 0x518A…8f26 e 0x31a1…ca9AB na mesma transação.

Passo 2: O contrato auxiliar 0x31a1…ca9AB envia uma requisição falsificada via HandlerV1, que não é rejeitada por VerifyProof)( devido à ausência de limite de leaf_index. A requisição falsa é considerada válida e aceita.

Passo 3: HandlerV1 distribui a requisição ao TokenGateway, que executa ChangeAssetAdmin, transferindo a administração do DOT para o contrato auxiliar 0x31a1…ca9AB.

Passo 4: O contrato auxiliar cunha 1 bilhão de DOT.

Passo 5: O contrato auxiliar troca os DOT cunhados por ETH via Odos Router V3.

Passo 6: O atacante transfere 108.2 ETH para sua conta EOA.

) Conclusão

O incidente foi causado por uma falha na lógica de validação de prova de MMR em HandlerV1, que não verifica se leaf_index < leafCount. Como resultado, uma carga falsificada pode passar na validação, mesmo que nunca tenha sido incluída na cadeia de origem. A mitigação é obrigar a verificação de limite de leaf_index antes de aceitar a prova.

Referências

BlockSec, “Análise do ataque Hyperbridge”, 13 de abril de 2026. https://x.com/Phalcon_xyz/status/2043601549893738970

Dango

Em 13 de abril de 2026, o Dango, uma DEX perpétua construída na Cosmos AppChain, foi atacado devido à falta de verificação de sinal, resultando em uma perda de aproximadamente US$ 1,5 milhão. A função replenish_insurance_fund[1]( usa is_non_zero)### ao invés de is_positive[1]( para validar o valor de entrada, permitindo que o atacante forneça um valor negativo de USDV e transfira fundos do fundo de seguro para sua posição de garantia.

) Contexto

Dango é uma DEX perpétua na Cosmos AppChain, onde usuários depositam USDC como garantia e abrem posições alavancadas de compra ou venda de ativos como BTC, ETH e SOL usando um livro de ordens centralizado on-chain. Cada usuário tem um saldo de garantia que acompanha sua posição.

Para proteger os provedores de liquidez (LP) de perdas, o protocolo mantém um fundo de seguro, que é uma reserva de USDC na posição perpétua, usada para cobrir déficits quando posições liquidadas não têm garantias suficientes para saldar dívidas. Sem esse fundo, os déficits seriam rateados entre os LPs. Qualquer usuário pode doar para o fundo de seguro a partir de sua garantia.

( Análise da vulnerabilidade

A causa raiz está na função replenish_insurance_fund)( do contrato 0x90bc84…bea4f, que não rejeita valores negativos. Existem duas verificações, mas ambas são insuficientes:

• ensure!)amount.is_non_zero######( verifica se o valor é diferente de zero, mas não se é positivo.

• ensure!)user_state.margin >= amount( verifica se a margem do usuário é maior ou igual ao valor, o que é verdadeiro para qualquer valor positivo, inclusive negativos.

Após essas verificações, o código executa user_state.margin.checked_sub_assign( e state.insurance_fund.checked_add_assign) com o valor de amount. Se amount for negativo, a subtracção aumenta a margem do usuário e diminui o fundo de seguro, invertendo a direção do fluxo de fundos.

![])https://img-cdn.gateio.im/social/moments-bfbc4f9ac0-5d013c5828-8b7abd-badf29(

Figura: trecho de replenish_insurance_fund sem verificação de sinal

) Análise do ataque

( Transação:

Fase 1:

O atacante deposita US$ 1 milhão na garantia, iniciando a chamada para replenish_insurance_fund)(.

Passo 1: Deposita US$ 1 milhão na garantia.

Passo 2: Chama replenish_insurance_fund)( com amount = -1.500.000. Como a validação é insuficiente, o valor negativo é aceito, transferindo US$ 1,5 milhão do fundo de seguro para a posição do atacante.

Passo 3: O atacante retira toda a garantia, obtendo US$ 1,5 milhão de USDC roubados.

![])https://img-cdn.gateio.im/social/moments-981929548c-dd4d29a21b-8b7abd-badf29###

Figura: rastreamento da transação de retirada de fundos roubados

Fase 2:

Nos passos 2 a 8, o atacante usa transfer_remote###( para transferir os fundos roubados para a Ethereum. No final, US$ 410 mil são bridgeados para a Ethereum.

) Conclusão

O ataque explora o uso de tipos inteiros com sinal em um contexto sem sinal, e a ausência de verificação de sinal na função. O valor USDV é um tipo com sinal, que pode ser negativo, e a função de doação ao fundo de seguro não verifica se o valor é positivo, permitindo que o atacante inverta o fluxo de fundos e roube US$ 1,5 milhão. A única limitação é a taxa de bridge, que impede a transferência de todo o valor de uma vez, mas não evita o roubo parcial.

Rhea Finance

Em 16 de abril de 2026, a plataforma de empréstimos e margem na NEAR, Burrowland, da Rhea Finance, foi atacada devido a uma falha na lógica de seu módulo de margem, resultando em uma perda de cerca de US$ 18,4 milhões. Ao abrir posições alavancadas, o protocolo usa verify_token_out() para validar a saída esperada de troca antes de aceitar a posição. No entanto, essa função incorretamente soma o valor de token_out nas etapas intermediárias de troca, sem considerar que esses valores podem ser reutilizados como token_in posteriormente. O atacante implantou tokens e pools falsos, construindo uma rota de troca circular que inflou artificialmente o valor percebido de saída, permitindo que a posição fosse aberta com uma avaliação inflada e que o protocolo pagasse uma quantia maior do que deveria, extraindo cerca de US$ 18,4 milhões.

( Contexto

Burrowland é um protocolo de empréstimo e margem open-source na NEAR. Além das funções padrão de empréstimo, suporta margem e introduz variáveis para posições alavancadas: token_c (colateral), token_d (ativo de dívida) e token_p (ativo da posição).

Para posições longas, o usuário deposita token_c como garantia e toma emprestado token_d com alavancagem (por exemplo, 5x). O token_d emprestado é trocado por token_p na DEX, criando uma exposição. Normalmente, o valor de token_p deve ser aproximadamente igual ao valor de token_d emprestado, e o protocolo mantém registro dessa posição.

Para posições curtas, o usuário deposita token_c e toma emprestado token_d (ativo que deseja vender a descoberto), trocando-o por token_p, formando uma posição vendida. O valor esperado é que a troca mantenha o valor constante.

Durante toda a vida útil da posição, token_p fica sob custódia do protocolo, e o usuário não pode retirá-lo diretamente. Para fechar a posição, o usuário troca token_p de volta por token_d para pagar a dívida.

A abertura de posições de margem é gerenciada por internal_margin_open_position)(, que define os parâmetros e distribui o empréstimo para a DEX.

![])https://img-cdn.gateio.im/social/moments-084491e5bb-d203f16753-8b7abd-badf29(

Figura: função internal_margin_open_position

Antes de aceitar a nova posição, o protocolo avalia quatro condições de proteção: is_min_amount_out_reasonable)###, que verifica se min_token_p_amount declarado pelo usuário faz sentido com a saída implícita do oráculo Pyth; is_open_position_liquidatable(), que verifica se a posição não está passível de liquidação; is_open_position_forcecloseable(), que verifica se a posição não está insolvente; e get_open_position_lr(), que garante que a relação token_d / token_c não ultrapasse o máximo de alavancagem.

Todas as verificações usam min_token_p_amount, pois a troca ainda não foi executada, e não há valores reais disponíveis. Assim, a validade de cada verificação depende de uma relação entre o valor declarado e a quantidade real de tokens que a troca entregará. Essa relação deveria ser garantida por verify_token_out###(, que deve validar a correspondência entre a mensagem de troca e o valor de saída esperado.

![])https://img-cdn.gateio.im/social/moments-5d0de6737a-27b31cb2f8-8b7abd-badf29(

Figura: verify_token_out e verificações de solvência

) Análise da vulnerabilidade

O problema está na implementação de verify_token_out(). Essa função assume que o valor de token_out na última etapa de troca é o valor final, e soma min_amount_out de todas as etapas que produzem o mesmo token. Essa lógica é válida para rotas de múltiplos caminhos, mas não para rotas circulares, onde o token_out pode ser consumido em etapas subsequentes antes de chegar ao final. Assim, uma rota do tipo A->B->A->B pode inflar artificialmente o valor declarado, pois cada etapa B->A também é somada, mesmo que seu output seja consumido posteriormente.

Essa falha permite que o atacante inflacione a soma de min_amount_out, fazendo com que as verificações de solvência aceitem posições que, na prática, não entregariam o valor declarado, levando o protocolo a aceitar posições insolventes.

Figura: verify_token_out

Figura: lógica de soma de token_out com falha

Se verify_token_out() for burlada, o valor inflado de min_token_p_amount será considerado verdadeiro em todas as verificações de solvência, permitindo que o atacante abra posições alavancadas com valores inflados, e que o protocolo distribua tokens de forma indevida, incluindo empréstimos e swaps, levando a perdas de milhões de dólares.

( Análise do ataque

Baseado na transação GcXEKm…fnFT.

Fase 1: Implantação de tokens e pools falsos

O atacante criou três tokens falsos e cinco pools falsos, com IDs como Fake1, Fake2, Fake3, Zec-Fake1, Fake1-Fake2, etc.

Fase 2: Abertura de posições de margem

Passo 1: O atacante usa a função de margem de Burrowland, depositando um ativo legítimo como token_c, e tomando emprestado um ativo real como token_d, criando uma posição alavancada. A troca de tokens é feita por rotas controladas pelo atacante, formando um ciclo A->B->A->B.

Passo 2: Como verify_token_out)( soma todos os min_amount_out de etapas que produzem o mesmo token, o atacante inflaciona o valor declarado de token_p.

Passo 3: Essa soma inflada passa nas verificações de solvência, e a posição é aberta, com tokens de empréstimo sendo enviados para pools controlados pelo atacante.

Passo 4: Como a troca circular retorna apenas uma quantidade pequena de token_p, o protocolo aceita a posição com uma avaliação inflada, levando a uma posição insolvente.

Passo 5: O atacante extrai o token_d emprestado, que está em pools controlados, e repete o ciclo até extrair cerca de US$ 18,4 milhões.

) Conclusão

O incidente foi causado por uma lógica incorreta na função verify_token_out(), que soma min_amount_out de etapas de troca, sem considerar que esses valores podem ser consumidos em etapas subsequentes. Essa falha permite inflar artificialmente a avaliação da posição, levando o protocolo a aceitar posições insolventes. Para evitar isso, a validação deve considerar apenas a última etapa de troca, ou implementar uma verificação que impeça a soma de valores de rotas circulares.

Referências

BlockSec, “Análise do ataque ao Hyperbridge”, 13 de abril de 2026. https://x.com/Phalcon_xyz/status/2043601549893738970