Top 3 Incidentes DeFi em Abril
KelpDAO: ~$290M
Em 18 de abril de 2026, a bridge rsETH LayerZero OFT da KelpDAO foi explorada por aproximadamente $290M.
A causa raiz foi a configuração DVN 1-de-1 insegura da KelpDAO, que reduziu a verificação de mensagens entre cadeias a um único ponto de falha. Após comprometer a infraestrutura RPC confiada pelo DVN da LayerZero Labs, o atacante forçou o único verificador a atestar uma mensagem forjada entre cadeias. Como resultado, 116.500 rsETH foram liberados na Ethereum sem nenhum evento correspondente no lado de origem na Unichain.
Este incidente não foi causado por uma falha no próprio protocolo LayerZero, mas por uma falha mais ampla de segurança operacional que abrangeu a configuração da bridge e as premissas de confiança da infraestrutura. Como a KelpDAO dependia de apenas um DVN, não havia verificador independente para contestar a mensagem forjada. Ao mesmo tempo, o atacante envenenou os nós RPC usados por esse DVN e executou um ataque DDoS nos nós saudáveis restantes, forçando o verificador a um estado de failover onde ele dependia inteiramente de dados controlados pelo atacante. Uma vez que a mensagem falsa foi atestada, o adaptador rsETH do lado da Ethereum executou conforme projetado e liberou os fundos, que foram rapidamente dispersos e lavados em múltiplas carteiras e cadeias.
Este incidente destaca que a segurança de bridges não pode depender exclusivamente da correção do protocolo. Os projetos devem adotar configurações multi-DVN com verificadores independentes, tratar interrupções repentinas de nós RPC durante a verificação como sinais de ataque em vez de problemas rotineiros de disponibilidade, e fortalecer a infraestrutura que fornece dados da cadeia de origem para as redes de verificadores.
Para uma análise detalhada, leia nossa publicação aprofundada:
Drift Protocol: ~$285M
Em 1º de abril de 2026, o Drift Protocol na Solana foi explorado por aproximadamente $285M.
A causa raiz não foi uma vulnerabilidade em contrato inteligente, mas uma falha no processo de governança e autorização do protocolo. Na época, o Drift utilizava uma configuração multisig 2-de-5 para ações de alto privilégio, o que significa que quaisquer dois dos cinco signatários autorizados podiam aprovar alterações administrativas críticas. Essas ações também não estavam sujeitas a nenhum timelock. Uma vez coletadas aprovações suficientes, elas podiam ser executadas imediatamente. Agravando esse risco estava o mecanismo de nonce durável da Solana, que permitia que transações pré-assinadas permanecessem válidas por um longo período em vez de expirar rapidamente como transações comuns. Isso deu ao atacante tempo para coletar assinaturas maliciosas antecipadamente e aguardar o momento certo para utilizá-las. Após induzir dois dos cinco signatários a aprovar transações de governança maliciosas, o atacante posteriormente submeteu essas transações para assumir o controle administrativo do protocolo. Com esse acesso, o atacante listou um ativo de garantia falso chamado CarbonVote Token (CVT), manipulou seu preço de Oracle, afrouxou as restrições de saque e usou a garantia falsa para drenar grandes quantidades de ativos reais por meio do Drift Vault.
Este incidente expôs três grandes fragilidades no design de governança do Drift. Primeiro, o atacante conseguiu separar a coleta de assinaturas da execução porque as aprovações roubadas não expiraram rapidamente. Segundo, a ausência de um timelock fez com que a tomada de controle administrativo fosse efetivada imediatamente, deixando quase nenhum tempo para detecção ou intervenção. Terceiro, o papel de administrador era muito poderoso: uma vez comprometido, permitiu que o atacante criasse um novo mercado de garantias, alterasse as configurações do oracle e relaxasse os controles de saque, todos os quais viabilizaram diretamente o roubo.
Este incidente mostra que a segurança de governança não se resume apenas à proteção de chaves privadas. Os protocolos também precisam proteger todo o processo de assinatura e aprovação, adicionar atrasos a ações de alto privilégio, limitar o uso de transações pré-assinadas de longa duração e reduzir o escopo do que uma única tomada de controle administrativo pode fazer.
Para uma análise detalhada, leia nossa publicação aprofundada:
Rhea Finance: ~$18,4M
Em 16 de abril de 2026, o protocolo Burrowland da Rhea Finance na NEAR foi explorado por aproximadamente $18,4M devido a uma falha de lógica de negócio em seu módulo de negociação com margem. Notavelmente, até 23 de abril de 2026, todos os fundos roubados haviam sido recuperados.
A causa raiz foi que o protocolo tratou uma declaração de saída de swap fornecida pelo usuário como se representasse com precisão o valor que seria efetivamente retornado pela DEX. No entanto, um usuário malicioso poderia construir um caminho de swap circular que reciclava saídas intermediárias dentro da rota, inflando artificialmente a saída final declarada e manipulando a contabilidade do protocolo. Como resultado, as verificações de solvência e alavancagem do protocolo dependiam de um valor fabricado em vez do valor real recebido. Essa falha estava enraizada na função verify_token_out(), que contabilizava incorretamente certas saídas intermediárias como parte do resultado final, mesmo que fossem posteriormente reutilizadas dentro do caminho de swap.
Após contornar essas verificações, o atacante roteou ativos emprestados para fora do protocolo por meio de pools falsas controladas pelo atacante, enquanto o protocolo recebia apenas uma quantidade insignificante de valor em troca. O atacante então retirou a liquidez dessas pools para extrair os fundos. Repetindo esse processo, o atacante acabou drenando aproximadamente $18,4M do Burrowland.
Este incidente mostra que protocolos de negociação com margem não devem tratar saídas de swap declaradas pelo usuário como entrada confiável. Os protocolos precisam garantir que as verificações de solvência sejam baseadas no valor efetivamente recebido, rejeitar caminhos de swap que possam reciclar ativos intermediários e impedir que a lógica contábil seja manipulada por roteamento circular.
As informações acima são baseadas em dados até 00:00 UTC, 29 de abril de 2026.
Isso conclui o resumo de incidentes de segurança de abril. Para análises mais aprofundadas de incidentes de segurança em blockchain e tendências de segurança Web3, você pode explorar nossos recursos.
Você pode saber mais em nossa Biblioteca de Incidentes de Segurança.
Mantenha-se informado e seguro!
