Resumo Semanal de Incidentes de Segurança Web3 | 13 a 19 de Abr de 2026

Durante a semana passada (2026/04/13 - 2026/04/19), a BlockSec detectou e analisou quatro incidentes de ataque, com perdas totais estimadas em aproximadamente $310M. A tabela abaixo resume esses incidentes, e análises detalhadas de cada caso são fornecidas nas subseções a seguir.

Destaque da Semana: KelpDAO

Para um relatório dedicado cobrindo a cascata pós-exploit, o mecanismo de recuperação on-chain da Arbitrum e as implicações mais amplas de governança, consulte: O Dilema da Descentralização: Risco em Cascata e Poder de Emergência na Crise do KelpDAO

Este incidente é destacado por seu novo vetor de ataque em nível de infraestrutura (envenenamento de RPC contra o único DVN, em vez de exploração de contrato inteligente), seu impacto em cascata em múltiplas cadeias via composabilidade DeFi, e as questões de governança levantadas pela transição de estado forçada da Arbitrum para recuperar os fundos roubados.

Em 18 de abril de 2026, a ponte LayerZero OFT rsETH da KelpDAO foi explorada em aproximadamente $290M em um ataque atribuído a um agente patrocinado por Estado, provavelmente o Grupo Lazarus da Coreia do Norte [1]. A causa raiz foi a configuração DVN 1-de-1 da KelpDAO, que reduziu a verificação de mensagens entre cadeias a um único ponto de falha. O atacante envenenou a infraestrutura RPC confiada pelo DVN da LayerZero Labs, forçando-a a atestar uma mensagem forjada entre cadeias que causou a liberação de 116.500 rsETH na Ethereum sem nenhum evento correspondente no lado da origem na Unichain.

Contexto

LayerZero é um protocolo de mensagens entre cadeias construído sobre uma arquitetura de segurança modular. Em seu núcleo, a integridade das mensagens entre cadeias é aplicada por Redes de Verificadores Descentralizados (DVNs), entidades off-chain responsáveis por verificar independentemente que uma mensagem enviada em uma cadeia de origem realmente ocorreu antes de ser executada na cadeia de destino. Cada aplicação implantada no LayerZero configura sua própria configuração DVN, incluindo quais DVNs confiar, quantos são necessários e qual limiar de consenso deve ser atingido. Essa modularidade dá às aplicações controle total sobre seu modelo de segurança, mas também responsabilidade total: uma configuração fraca não pode ser compensada pelo próprio protocolo.

O rsETH da KelpDAO é implantado como um OFT (Omnichain Fungible Token) no LayerZero, com uma rota de bridge conectando Unichain (origem) e a rede principal Ethereum (destino). O padrão OFT permite que tokens sejam queimados na cadeia de origem e liberados de um bloqueio na cadeia de destino, com a mensagem entre cadeias servindo como única autorização para a liberação. O adaptador do lado Ethereum (0x85d456...e98ef3) é responsável por liberar rsETH para os destinatários após uma mensagem válida entre cadeias ter sido verificada e entregue. De forma crítica, a KelpDAO configurou esse caminho com uma configuração DVN 1-de-1, designando a LayerZero Labs como o único verificador. Isso significa que uma única atestação DVN era suficiente para autorizar qualquer liberação de tokens, sem necessidade de uma segunda opinião.

Para realizar suas funções de verificação, o DVN da LayerZero Labs consulta múltiplos nós RPC para confirmar que um evento de envio entre cadeias realmente ocorreu na cadeia de origem. Esses nós RPC incluem tanto infraestrutura operada internamente quanto provedores externos, e o DVN depende de suas respostas coletivas antes de assinar uma atestação. A integridade desse processo depende da suposição de que a maioria dos nós consultados retorna dados verdadeiros.

Análise de Vulnerabilidade

A vulnerabilidade é uma falha sistêmica no nível de infraestrutura e configuração, composta por três fraquezas compostas.

Primeiro, a configuração DVN 1-de-1 da KelpDAO eliminou toda redundância na camada de verificação. A postura de segurança recomendada pelo LayerZero exige explicitamente configurações multi-DVN com verificadores independentes, de modo que nenhum DVN único possa autorizar unilateralmente uma mensagem. Ao depender exclusivamente do DVN da LayerZero Labs, a KelpDAO garantiu que qualquer comprometimento desse único verificador seria suficiente para autorizar uma liberação arbitrária de tokens.

Segundo, o mecanismo de failover do DVN roteia consultas de verificação para quaisquer nós RPC que permaneçam acessíveis. Esse design pressupõe que a indisponibilidade de nós é acidental, e não deliberada. No entanto, cria uma condição em que um atacante não precisa comprometer todas as fontes de dados: ao tirar os nós saudáveis offline via DDoS e ter nós envenenados prontos como única alternativa acessível, o atacante pode obter controle total sobre os dados que o DVN recebe.

Terceiro, substituir o executável op-geth nos nós RPC exigia acesso em nível de SO aos servidores subjacentes. O vetor de acesso inicial exato não foi divulgado, mas comprometer dois nós independentes em clusters separados pode indicar uma fraqueza compartilhada na forma como o acesso a esses servidores era controlado.

Juntas, essas três condições formaram uma cadeia de ataque completa: a primeira garantiu que não havia DVN independente para verificar a mensagem atestada, a segunda garantiu que o atacante pudesse controlar completamente os dados que o único DVN recebia, e a terceira forneceu o ponto de entrada inicial que tornou a manipulação de dados possível. Nenhuma fraqueza isolada seria suficiente. Sem a configuração 1-de-1, um segundo DVN consultando infraestrutura independente teria rejeitado a mensagem forjada. Sem o comportamento de failover, os nós saudáveis teriam superado os nós envenenados em votação. Sem o comprometimento do servidor, o atacante não teria como injetar dados forjados em primeiro lugar.

Análise do Ataque

A análise a seguir é baseada na transação 0x1ae232...4222 e no comunicado oficial de incidente da LayerZero Labs.

• Passo 1: O atacante obteve a lista de nós RPC específicos confiados pelo DVN da LayerZero Labs. Essa lista constituía um alvo de inteligência de alto valor, porque conhecer os nós exatos permitiu ao atacante planejar uma operação cirúrgica em vez de um ataque amplo à infraestrutura.

• Passo 2: O atacante obteve acesso de escrita em nível de SO a dois dos nós RPC e substituiu os binários op-geth em execução por versões maliciosas. Esses dois nós foram descritos como executando em clusters independentes sem conexão direta entre si, sugerindo que o vetor de acesso inicial envolveu uma dependência upstream compartilhada (por exemplo, credenciais de implantação comprometidas, um pipeline CI/CD ou engenharia social de um operador com acesso a ambos). O método exato de acesso inicial não foi divulgado pela LayerZero Labs. Este passo foi o pré-requisito para toda a manipulação de dados subsequente.

• Passo 3: O binário op-geth malicioso implementou lógica de resposta direcionada: retornou dados de transação forjados exclusivamente para o endereço IP do DVN, enquanto servia o estado verdadeiro da blockchain para todos os outros solicitantes, incluindo a própria infraestrutura de monitoramento da LayerZero, exploradores de blocos e serviços de varredura. Esse envenenamento seletivo tornou o ataque invisível para todos os sistemas de observabilidade existentes; de toda perspectiva externa, a cadeia de origem parecia normal.

• Passo 4: O consenso interno do DVN exigia concordância entre os nós RPC envenenados e os não comprometidos. Para resolver esse conflito, o atacante realizou DDoS nos nós saudáveis restantes durante a janela de ataque (10h20 às 11h40 PT), acionando a lógica de failover do DVN e forçando-o a depender exclusivamente da infraestrutura envenenada. Este passo foi necessário porque os nós saudáveis, de outra forma, teriam retornado dados verdadeiros que contradiziam as respostas forjadas.

• Passo 5: Com o DVN recebendo apenas dados controlados pelo atacante, uma mensagem LayerZero forjada entre cadeias foi apresentada como válida. O DVN atestou o nonce 308 no endpoint de destino Ethereum, um nonce que não tinha nenhum evento de saída correspondente na Unichain (confirmado pelo endpoint de origem ainda reportando um nonce de saída máximo de 307).

• Passo 6: O adaptador rsETH do lado Ethereum, ao receber uma mensagem validamente atestada, liberou 116.500 rsETH para o endereço destinatário do atacante (0x8b1b6c...0d3b), que havia sido pré-financiado via Tornado Cash horas antes. Os tokens roubados foram imediatamente dispersos por sete carteiras ramificadas e liquidados por meio de posições de colateral Aave, swaps diretos de ETH e re-bridge para Arbitrum, com os rendimentos finais consolidando em 0x5d3919...7ccc na Ethereum e um coletor correspondente na Arbitrum.

• Passo 7: O binário malicioso executou uma rotina de autodestruição após a conclusão, deletando a si mesmo junto com todos os logs locais e arquivos de configuração. Isso dificultou significativamente a recuperação forense pós-incidente e ilustra a sofisticação operacional do atacante.

• Passo 8: Uma tentativa subsequente do atacante de explorar o mesmo caminho para um adicional de 40.000 rsETH (~$95M) foi bloqueada após a KelpDAO detectar a anomalia e pausar todos os contratos relevantes na rede principal Ethereum e nas L2s [2].

Impacto Mais Amplo

O dano se estendeu muito além do exploit inicial de bridge de $290M. O atacante depositou aproximadamente 89.567 rsETH (~$221M) no Aave em múltiplos mercados, tomando WETH emprestado no LTV de 93% do E-Mode [4]. Como o Aave não conseguia distinguir rsETH legitimamente bridge de tokens liberados via uma mensagem forjada, o colateral "envenenado" foi tratado como totalmente válido. O congelamento resultante das reservas de WETH se propagou pela Ethereum, Arbitrum, Base, Mantle e Linea, afetando usuários que não tinham nenhuma exposição ao rsETH. Essa propagação em cascata — de uma única falha de configuração de bridge para a perturbação de mercados de empréstimo em múltiplas cadeias — ilustra como a composabilidade DeFi amplifica tanto o alcance quanto o custo de um único ponto de falha.

O pós-incidente levantou questões igualmente importantes sobre a realidade operacional da descentralização. A LayerZero Labs anunciou que seu DVN não assinará mais mensagens para aplicações que usam configurações 1-de-1 [1], implicando que a descentralização em nível de protocolo por si só não pode compensar fraquezas de configuração em nível de aplicação.

No nível da cadeia, o Conselho de Segurança da Arbitrum executou uma ação de emergência para congelar 30.766 ETH mantidos pelo atacante na Arbitrum One. Conforme analisado pela BlockSec [5], isso foi realizado por meio de uma transição de estado forçada em nível de cadeia: o Conselho de Segurança atualizou temporariamente o contrato de inbox da Ethereum, injetou uma mensagem L1-para-L2 não assinada se passando pelo endereço do atacante e restaurou a implementação original, tudo sem exigir a assinatura do titular [3].

Essa ação foi um exercício legítimo de poderes de emergência definidos pela governança, conduzido de forma transparente e em coordenação com as autoridades policiais. No entanto, também demonstra que as cadeias L2 retêm capacidades de intervenção centralizada por design: qualquer ativo na Arbitrum One pode, em princípio, ser movido pelo Conselho de Segurança pelo mesmo mecanismo. A lacuna entre o modelo de confiança teórico de um sistema e seu limite de confiança real é, como este incidente mostra em todas as camadas, onde residem os riscos mais consequentes.

Conclusão

Este incidente demonstra que a segurança de bridges não pode ser reduzida apenas à correção do protocolo. O próprio protocolo LayerZero funcionou conforme projetado; a vulnerabilidade existia inteiramente na camada operacional acima dele. A lição central é que a infraestrutura de verificação off-chain faz parte do limite de confiança, e sua postura de segurança deve corresponder ao valor que protege.

Três mitigações teriam individualmente evitado esse resultado:

• Configuração multi-DVN: Exigir consenso entre múltiplos DVNs independentes teria tornado o comprometimento de um único DVN insuficiente para autorizar uma mensagem, independentemente de quão completamente esse DVN fosse enganado.

• Seleção de RPC ciente de failover: Uma queda repentina nos nós acessíveis durante uma janela de verificação ativa deve ser tratada como um possível sinal de ataque, e não como um evento de disponibilidade rotineiro. As implementações de DVN devem pausar ou alertar em vez de prosseguir com um conjunto reduzido de nós.

• Fortalecimento da infraestrutura RPC: A capacidade de substituir um executável em execução em um nó RPC de produção indica controles de acesso insuficientes nos servidores subjacentes. A infraestrutura da qual os DVNs dependem para a verdade fundamental da cadeia de origem deve estar sujeita ao mesmo limite de segurança que as próprias instâncias de assinatura DVN.

De forma mais ampla, qualquer bridge ou protocolo entre cadeias que dependa de atestação off-chain deve auditar não apenas a camada de contrato inteligente, mas o pipeline completo de dados desde o evento na cadeia de origem até a execução na cadeia de destino. A suposição de que a infraestrutura RPC é confiável por padrão não é mais sustentável quando centenas de milhões de dólares dependem dela.

Referências

[1] LayerZero Labs, "Comunicado de Incidente KelpDAO," 20 de abril de 2026. https://x.com/LayerZero_Core/status/2046081551574983137

[2] KelpDAO, "Incidente de 18 de abril: Contexto Adicional," 21 de abril de 2026. https://x.com/KelpDAO/status/2046332070277091807

[3] Arbitrum, "Ação de Emergência do Conselho de Segurança," 21 de abril de 2026. https://x.com/arbitrum/status/2046435443680346189

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

[5] BlockSec, "Análise do Mecanismo de Congelamento do Conselho de Segurança da Arbitrum," 21 de abril de 2026. https://x.com/Phalcon_xyz/status/2046467830498173088

Mais Incidentes desta Semana

Rhea Finance

Em 16 de abril de 2026, o Burrowland, um protocolo de empréstimo e negociação com margem na NEAR sob a Rhea Finance, foi explorado em aproximadamente $18.4M devido a uma falha de lógica de negócio em seu módulo de negociação com margem. Ao abrir uma posição alavancada, o protocolo depende de verify_token_out() para validar o resultado esperado do swap antes de aceitar a posição. No entanto, essa função acumulava incorretamente valores de token_out de etapas intermediárias do swap sempre que o token correspondia ao token de saída final, deixando de considerar que esses valores intermediários eram subsequentemente reutilizados como token_in. O atacante implantou tokens e pools falsos, depois construiu um caminho de swap circular que inflou o valor de saída percebido e passou nas verificações de solvência, drenando aproximadamente $18.4M do protocolo.

Contexto

Burrowland é um protocolo de empréstimo e negociação com margem de código aberto na NEAR. Além da funcionalidade padrão de fornecimento e empréstimo, ele suporta negociação com margem e introduz três variáveis-chave para representar a posição alavancada de um usuário: token_c (colateral), token_d (ativo de dívida) e token_p (ativo de posição).

Para uma posição comprada, o usuário deposita token_c como colateral e toma token_d emprestado com uma alavancagem escolhida (por exemplo, 5x). O token_d emprestado é então trocado em uma DEX por token_p, o ativo ao qual o usuário deseja exposição. Em condições normais, o valor de token_p recebido é aproximadamente igual ao valor de token_d gasto. O protocolo mantém token_p em nome do usuário, enquanto registra o token_d emprestado como dívida.

Para uma posição vendida, o usuário também deposita token_c e toma token_d emprestado (o ativo que deseja vender a descoberto) com alavancagem. O token_d emprestado é trocado por outro ativo (token_p), efetivamente assumindo uma exposição vendida ao token_d. Novamente, espera-se que o swap preserve o valor em condições normais de mercado.

Durante todo o ciclo de vida da posição, token_p permanece custodiado dentro do protocolo e o usuário não pode retirá-lo diretamente. A posição deve ser fechada para realizar lucro ou prejuízo, momento em que token_p é trocado de volta por token_d para pagar a dívida.

A abertura de uma posição com margem é tratada por internal_margin_open_position(), que configura os parâmetros da posição e despacha o empréstimo para a DEX.

Antes de o protocolo aceitar uma nova posição, ele avalia quatro proteções em sequência: is_min_amount_out_reasonable() faz uma verificação cruzada do min_token_p_amount declarado pelo usuário em relação à saída de swap implícita pelo oráculo Pyth para limitar o slippage, is_open_position_liquidatable() verifica que o valor esperado da posição e do colateral supera o limite de liquidação, is_open_position_forcecloseable() verifica que a conta não está já insolvente no papel, e get_open_position_lr() garante que o valor de token_d / token_c não exceda a taxa máxima de alavancagem.

Todas as quatro verificações usam min_token_p_amount como o valor do ativo de posição, porque o swap ainda não foi executado e não há valor realizado para usar. A correção de cada barreira depende, portanto, de min_token_p_amount estar vinculado ao que a DEX realmente entregará. Esse vínculo é exatamente o que verify_token_out(), implementado via RefV1TokenReceiverMessage::get_token_out(), supostamente aplica na mensagem de swap que o usuário envia.

Análise de Vulnerabilidade

A falha está dentro de verify_token_out(). A função escolhe o token_out da última etapa do swap como o token de saída final e, em seguida, soma o min_amount_out declarado de cada etapa do swap que produz o mesmo token, assumindo que cada tal produção contribui para a saída final. Isso está correto para um swap genuíno de múltiplos caminhos (rota dividida), mas não exclui etapas cujo token_out é imediatamente consumido como o token_in da próxima etapa. Um caminho de ida e volta como A->B->A->B faz com que cada etapa ->B seja contada para a soma, mesmo que sua saída seja gasta na etapa seguinte B->A e nunca alcance o Burrowland. O min_amount_out somado que verify_token_out() aprova não representa mais o que a DEX realmente retornará.

Uma vez que verify_token_out() é contornado, o min_token_p_amount inflado é tratado como verdade absoluta em todo internal_margin_open_position(). Cada barreira de solvência que deveria impedir uma abertura insegura calcula contra um número fabricado, portanto a posição é aceita e o protocolo despacha o token_d emprestado para a Ref-Finance com a mensagem de swap circular anexada.

Análise do Ataque

A análise a seguir é baseada na transação GcXEKm...fnFT.

Fase 1: Implantação de Tokens e Pools Falsos

O atacante implantou três tokens falsos e criou cinco pools falsos.

1. IDs de Tokens Falsos:

   1. Falso1: 31623e1d98275d2b0db4f50e102f6bf40877c1345e06e4ca6727f58c89564bb2

   2. Falso2: 6a28e3d3c7af1415ec22c6264013e1138bab00f85b8b6055d882d7d46afdf49b

   3. Falso3: e081e03daf58f5bb04cf95a03017e58449b76e704f1974771d7e3bd52835b6e5

2. IDs de Pools Falsos:

   1. Zec-Falso1: 7509

   2. Falso1-Falso2: 7510

   3. USDC-Falso2: 7511

   4. Falso2-Falso3: 7512

   5. Falso3-USDC: 7513

Fase 2: Abertura de Posição com Margem

• Passo 1: Usando o recurso de negociação com margem do Burrowland, o atacante abriu uma posição alavancada com um ativo legitimamente valioso como token_c e um ativo de reserva real como token_d, anexando uma mensagem de swap cuja lista de ações é um caminho de ida e volta A->B->A->B roteado inteiramente pelos pools controlados pelo atacante da Fase 1.

• Passo 2: Como verify_token_out() soma min_amount_out em cada etapa cujo token_out corresponde à saída terminal, o caminho de ida e volta permitiu ao atacante inflar o min_token_p_amount declarado para um valor arbitrário.

• Passo 3: O min_token_p_amount inflado passou em todas as verificações de saúde no momento da abertura em internal_margin_open_position(), portanto a posição foi aceita e o protocolo despachou token_d para a Ref-Finance.

• Passo 4: O swap circular retornou apenas uma quantidade mínima de token_p; on_open_trade_return() a registrou sem nenhuma nova verificação, deixando a posição insolvente desde a criação.

• Passo 5: O token_d emprestado ficou dentro dos pools controlados pelo atacante ao longo do caminho; o atacante o extraiu via remove_liquidity().

• Passo 6: Como o empréstimo é alavancado, o token_d retirado vale mais do que o token_c depositado. A diferença é lucro líquido por ciclo, e a dívida incobrável é encerrada forçosamente em protocol_debts. O atacante repetiu a construção até que aproximadamente $18.4M fossem drenados.

Conclusão

Este incidente foi causado por uma falha de lógica de negócio no caminho de abertura de margem do Burrowland. A função RefV1TokenReceiverMessage::get_token_out() agregou incorretamente saídas intermediárias sempre que correspondiam ao token final, assumindo que esses valores permaneceriam como saída final. No entanto, caminhos de swap circulares quebram essa suposição, pois esses tokens podem ser reutilizados e consumidos dentro do caminho. Como resultado, o min_token_p_amount computado pode ser artificialmente inflado, fazendo com que todas as verificações de solvência subsequentes dependam de um valor incorreto e permitindo que posições sejam abertas contra um estado de saúde fabricado sem validar o valor realmente recebido.

Para contratos de negociação com margem em produção, os desenvolvedores devem:

• Tratar o min_amount_out declarado pelo usuário como entrada não verificada, e tomar apenas o min_amount_out do último salto ou rejeitar explicitamente caminhos de swap que reconsumam um token_out previamente produzido (sem ciclos pelo alvo).

• Delimitar o slippage declarado com um envelope inferior e superior em relação à saída de swap implícita pelo oráculo, de modo que um atacante não possa inflar unilateralmente o valor declarado para contornar os predicados de solvência.

Hyperbridge

Em 13 de abril de 2026, o Hyperbridge, uma bridge de mensagens entre cadeias na Ethereum, foi explorado em aproximadamente $242K devido à ausência de validação de entrada na lógica de verificação de prova MMR (Merkle Mountain Range). A função MerkleMountainRange.VerifyProof() não verificava se leaf_index < leafCount, permitindo ao atacante forjar uma prova entre cadeias e realizar ações privilegiadas, incluindo a criação de 1.000.000.000 tokens DOT.

Contexto

O Hyperbridge usa um modelo de verificador e despachante do lado Ethereum para mensagens entre cadeias. Na Ethereum, o contrato HandlerV1 valida as provas fornecidas em relação ao overlayRoot armazenado e, se a prova for aceita, despacha a mensagem para módulos de destino como o contrato TokenGateway.

O contrato TokenGateway é um módulo privilegiado de gerenciamento de ativos. Além do bridge normal de ativos, ele também suporta ações no estilo de governança, como criação de ativos, cancelamento de registro e gerenciamento de administradores. Para ativos com bridge implementados como ERC6160Ext20, o administrador pode transferir diretamente a autoridade de criação chamando a função changeAdmin(), e o novo administrador pode então criar fornecimento arbitrário via a função mint().

Isso significa que a segurança de toda a bridge de ativos depende da correção do caminho de verificação de prova em HandlerV1. Se uma mensagem forjada puder passar na verificação, os módulos downstream tratarão os payloads controlados pelo atacante como instruções autênticas entre cadeias.

Análise de Vulnerabilidade

O problema central está no fluxo de verificação de prova MMR no contrato HandlerV1 (0x6c84ed...6d64). A função de entrada handlePostRequests() primeiro constrói MmrLeaf(leaf.kIndex, leaf.index, commitment) com base nas entradas fornecidas pelo atacante. Em seguida, MerkleMountainRange.VerifyProof() é invocado para realizar a validação da prova.

MerkleMountainRange.VerifyProof(root, request.proof.multiproof, leaves, request.proof.leafCount)

No entanto, VerifyProof() apenas verifica se root == CalculateRoot(proof, leaves, mmrSize) e não valida que cada leaf.index está dentro do intervalo (ou seja, leaf.index < leafCount). Ao escolher leafCount = 1 e leaf_index = 1, o atacante faz CalculateRoot() pular a incorporação do commitment de solicitação forjado na raiz calculada, retornando a raiz de pico diretamente. Isso quebra o vínculo mensagem-prova e permite que payloads arbitrários passem como válidos em relação a um overlayRoot histórico.

Análise do Ataque

A análise a seguir é baseada na transação 0x240aeb...1109 [1].

• Passo 1: O EOA atacante 0xC513...F8E7 implantou os contratos auxiliares 0x518A...8f26 e 0x31a1...ca9AB na mesma transação.

• Passo 2: O contrato auxiliar 0x31a1...ca9AB enviou uma solicitação forjada pelo caminho de verificação vulnerável em HandlerV1. Como VerifyProof() não rejeitou o leaf_index fora dos limites, o commitment de solicitação forjado foi omitido do cálculo da raiz, mas a prova ainda correspondia a um overlayRoot histórico.

• Passo 3: Após a mensagem forjada ser aceita, HandlerV1 a despachou para TokenGateway, executando a ação ChangeAssetAdmin. Isso alterou o administrador do token DOT para o contrato auxiliar controlado pelo atacante 0x31a1...ca9AB.

• Passo 4: O contrato auxiliar criou 1.000.000.000e18 tokens DOT.

• Passo 5: O contrato auxiliar trocou os tokens DOT recém-criados por 108,2 ETH via Odos Router V3.

• Passo 6: O atacante transferiu 108,2 ETH para sua conta EOA.

Conclusão

Este incidente foi causado por validação inadequada de prova na lógica de verificação MMR do Hyperbridge. Como leaf_index < leafCount não foi verificado, o atacante poderia forjar uma mensagem cujo commitment nunca foi realmente incluído na raiz calculada, mas ainda assim passar na verificação em relação a uma raiz de estado histórica. As mitigações devem aplicar verificações estritas de limites como leaf_index < leafCount antes da verificação da prova.

Referências

[1] BlockSec, "Análise do Ataque ao Hyperbridge," 13 de abril de 2026. https://x.com/Phalcon_xyz/status/2043601549893738970

Dango

Em 13 de abril de 2026, o Dango, uma DEX de futuros perpétuos construída como uma Cosmos AppChain, foi explorado em aproximadamente $1.5M devido à ausência de verificação de sinal. A função replenish_insurance_fund() usou is_non_zero() em vez de is_positive() para validar o valor de entrada, permitindo ao atacante fornecer um UsdValue negativo e drenar o fundo de seguro para sua posição de margem.

Contexto

Dango é uma DEX de futuros perpétuos construída como uma Cosmos AppChain. Os usuários depositam USDC como colateral no contrato de perps e abrem posições compradas ou vendidas alavancadas em ativos como BTC, ETH e SOL por meio de um Livro de Ordens de Limite Central (CLOB) on-chain. O saldo de colateral de cada usuário é rastreado como uma conta de margem dentro do contrato de perps.

Para proteger os provedores de liquidez (LPs) de perdas por dívidas incobráveis, o protocolo mantém um fundo de seguro: uma reserva de USDC mantida dentro do contrato de perps que cobre qualquer déficit quando o colateral de uma posição liquidada é insuficiente para pagar totalmente sua dívida. Sem ele, tais déficits seriam socializados diretamente sobre os LPs. Qualquer usuário poderia contribuir com margem de sua conta perp para o fundo de seguro.

Análise de Vulnerabilidade

A causa raiz está na função replenish_insurance_fund() do contrato 0x90bc84...bea4f, que falha em rejeitar valores de entrada negativos. A função tem duas proteções, mas nenhuma impede um amount negativo:

1. ensure!(amount.is_non_zero()) verifica que o valor não é zero, mas não verifica se é positivo.
2. ensure!(user_state.margin >= amount) verifica que o usuário tem margem suficiente, mas qualquer margem positiva satisfaz >= número_negativo.

Com ambas as proteções passadas, a função executa user_state.margin.checked_sub_assign(amount) e state.insurance_fund.checked_add_assign(amount). Quando amount é negativo, subtraí-lo aumenta a margem do usuário, e adicioná-lo diminui o fundo de seguro, revertendo completamente o fluxo de fundos pretendido.

Análise do Ataque

Transações:

Fase 1:

Na Tx 1, o atacante realizou as seguintes etapas para drenar ativos do fundo de seguro do Dango:

• Passo 1: O atacante abriu uma posição de margem depositando 1e6 USDC. Este foi um pré-requisito para invocar replenish_insurance_fund().

• Passo 2: O atacante invocou replenish_insurance_fund() com um amount negativo (ou seja, -1500000). Devido à validação inadequada, o amount negativo foi aceito, drenando ativos do fundo de seguro para a posição de margem do atacante.

• Passo 3: O atacante retirou todos os ativos da posição de margem, obtendo $1.500.000 em USDC.

Fase 2:

Nas Tx 2-8, o atacante invocou transfer_remote() para fazer bridge dos ativos roubados para a Ethereum. Como resultado, $410.000 em USDC foram transferidos via bridge para a Ethereum.

Conclusão

A essência deste ataque é um tipo inteiro com sinal usado em um contexto sem sinal sem uma proteção de sinal. O tipo UsdValue é assinado por design (o PnL de perps pode ser negativo), mas o caminho de doação ao fundo de seguro só faz sentido para contribuições positivas. Usar is_non_zero() em vez de is_positive() deixou uma lacuna de uma palavra que permitiu a qualquer chamador inverter a direção do fluxo de fundos, drenando USDC do fundo de seguro para sua própria margem. O atacante executou todo o ataque em uma única transação (depositar $1, drenar $1.5M, retirar $1.500.001) e depois lentamente fez bridge dos fundos para fora. O limite de taxa de bridge foi o único mecanismo que limitou o dano: sem ele, todo o ~$1.5M teria sido irrevogavelmente transferido via bridge para a Ethereum.

Sobre a BlockSec

A BlockSec é uma provedora completa de segurança em blockchain e conformidade cripto. Desenvolvemos produtos e serviços que ajudam os clientes a realizar auditorias de código (incluindo contratos inteligentes, blockchain e carteiras), interceptar ataques em tempo real, analisar incidentes, rastrear fundos ilícitos e cumprir obrigações de AML/CFT, ao longo de todo o ciclo de vida de protocolos e plataformas.

A BlockSec publicou múltiplos artigos de segurança em blockchain em conferências de prestígio, reportou vários ataques de dia zero em aplicações DeFi, bloqueou múltiplos hacks para resgatar mais de 20 milhões de dólares e protegeu bilhões em criptomoedas.

• Site oficial: https://blocksec.com/

• Conta oficial no Twitter: https://twitter.com/BlockSecTeam

• 🔗 Serviço de Auditoria BlockSec : Enviar uma solicitação

• 🔗 Phalcon Security APP: Agendar uma demonstração

• 🔗 Phalcon Compliance