Top 3 Incidentes DeFi em Abril
KelpDAO: ~$290M
Em 18 de abril de 2026, a ponte rsETH LayerZero OFT da KelpDAO foi explorada por aproximadamente $290M.
A causa raiz foi a configuração DVN insegura de 1-de-1 da KelpDAO, que reduziu a verificação de mensagens entre cadeias a um único ponto de falha. Após comprometer a infraestrutura RPC confiada pela LayerZero Labs DVN, o atacante forçou o único verificador a atestar uma mensagem entre cadeias fabricada. Como resultado, 116.500 rsETH foram liberados na Ethereum sem qualquer evento correspondente do lado de origem na Unichain.
Esse incidente não foi causado por uma falha no próprio protocolo LayerZero, mas por uma falha operacional de segurança mais amplo, envolvendo a configuração da ponte e as premissas de confiança na 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 realizou um DDoS nos demais nós saudáveis, forçando o verificador a um estado de failover no qual passou a depender 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 então rapidamente dispersos e lavados em múltiplas carteiras e cadeias.
Esse incidente evidencia que a segurança de pontes não pode depender apenas da correção do protocolo. Os projetos devem adotar configurações multi-DVN com verificadores independentes, tratar interrupções súbitas de nós RPC durante a verificação como sinais de ataque, e não como problemas rotineiros de disponibilidade, e reforçar a infraestrutura que alimenta os dados da cadeia de origem para as redes de verificadores.
Para uma análise detalhada, leia nosso post de aprofundamento:
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 de contrato inteligente, mas uma falha no processo de governança e autorização do protocolo. Na época, a Drift utilizava uma configuração multisig de 2-de-5 para ações de alto privilégio, o que significa que quaisquer dois dos cinco signatários autorizados poderiam 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 muito tempo, em vez de expirarem rapidamente como transações comuns. Isso deu ao atacante tempo para coletar assinaturas maliciosas com antecedência e esperar o momento certo para usá-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 colateral falso chamado CarbonVote Token (CVT), manipulou seu preço no Oracle, afrouxou as restrições de retirada e usou o colateral falso para drenar grandes quantidades de ativos reais através do Drift Vault.
Esse incidente expôs três grandes fragilidades no design de governança da Drift. Primeiro, o atacante conseguiu separar a coleta de assinaturas da execução, pois as aprovações roubadas não expiravam rapidamente. Segundo, a ausência de um timelock significou que a tomada do controle administrativo se tornou efetiva imediatamente, deixando quase nenhum tempo para detecção ou intervenção. Terceiro, o papel de administrador era excessivamente poderoso: uma vez comprometido, permitiu ao atacante criar um novo mercado de colateral, alterar as configurações do oráculo e relaxar os controles de retirada, tudo isso possibilitando diretamente o roubo.
Esse incidente mostra que a segurança da governança não se trata apenas de proteger 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 alcance do que uma única tomada administrativa pode fazer.
Para uma análise detalhada, leia nosso post de aprofundamento:
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 margem de negociação. Notavelmente, em 23 de abril de 2026, todos os fundos roubados haviam sido recuperados.
A causa raiz foi que o protocolo tratava uma declaração de saída de swap fornecida pelo usuário como se ela representasse com precisão o valor que seria efetivamente retornado pela DEX. Contudo, 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 teve origem na função verify_token_out(), que contava incorretamente certas saídas intermediárias como parte do resultado final, mesmo que fossem reutilizadas posteriormente dentro do caminho de swap.
Após contornar essas verificações, o atacante direcionou ativos emprestados para fora do protocolo por meio de pools falsos controlados pelo atacante, enquanto o protocolo recebia em troca apenas um valor insignificante. O atacante então retirou liquidez desses pools para extrair os fundos. Ao repetir esse processo, o atacante acabou drenando aproximadamente $18,4M do Burrowland.
Esse incidente mostra que protocolos de margem de negociação 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 de contabilidade seja manipulada por meio de roteamento circular.
Melhor Auditor de Segurança para Web3
Valide o design, o código e a lógica de negócio antes do lançamento
As informações acima são baseadas em dados de 00:00 UTC, 29 de abril de 2026.
Este é o encerramento do resumo de incidentes de segurança de abril.
Você pode saber mais em nossa Security Incidents Library.
Mantenha-se informado e seguro!
