O erro de 293 milhões de dólares não estava no código; então, o que se passa com o «erro de configuração DVN», que levou ao maior ataque informático de 2026?

Em 18 de abril de 2026, o protocolo de restaking de liquidez da Kelp DAO foi alvo de um ataque, tendo o atacante desviado 116 500 rsETH de uma ponte inter-cadeias em poucas horas, o que correspondia a aproximadamente 293 milhões de dólares na altura. Todo o processo foi executado de forma eficiente, com um toque de irregularidade, começando por uma mensagem entre cadeias falsificada e passando pela lavagem dos fundos roubados através dos protocolos de empréstimo Aave V3, Compound V3 e Euler, com ativos reais tomados em empréstimo. O atacante retirou rapidamente 236 milhões de dólares em WETH no mesmo dia. A Aave, a SparkLend e a Fluid suspenderam imediatamente o mercado de rsETH.

Este é o maior caso de exploração de vulnerabilidades na DeFi de 2026.

No entanto, há um aspeto que distingue este ataque da maioria dos incidentes de pirataria informática. O código do contrato inteligente da Kelp DAO não apresentava vulnerabilidades. O investigador de segurança @0xQuit, envolvido na investigação, afirmou no X: «Pelo que percebo neste momento, trata-se de uma combinação de duas questões: uma configuração DVN 1-de-1 e o comprometimento do próprio nó DVN.» No seu comunicado oficial, a LayerZero não atribuiu a culpa ao código do contrato, classificando o problema como uma «vulnerabilidade do rsETH» e não como uma «vulnerabilidade da LayerZero».

Os 293 milhões de dólares não constavam em nenhuma linha de código. Estava oculto num parâmetro mal configurado durante a implementação.

A lógica comum subjacente às auditorias de segurança da DeFi é a seguinte: localizar o contrato, ler o código, identificar vulnerabilidades. Esta lógica funciona muito bem quando se trata de vulnerabilidades de lógica de código. Ferramentas como o Slither e o Mythril são eficazes na deteção de padrões conhecidos, tais como ataques de reentrância e transbordamentos de inteiros. O LLM amplamente divulgado para auxiliar nas auditorias de código também possui alguma capacidade para identificar vulnerabilidades na lógica de negócio (por exemplo, percursos de arbitragem de empréstimos instantâneos).

No entanto, nesta matriz, duas linhas estão assinaladas a vermelho.

As vulnerabilidades ao nível da configuração constituem um ponto cego estrutural nas auditorias realizadas com base em ferramentas. O problema com o Kelp DAO não residia num ficheiro .sol, mas sim num parâmetro — o limiar DVN — definido durante a implementação do protocolo. Este parâmetro determina por quantos nós de validação uma mensagem entre cadeias deve passar para ser considerada válida. Não está no código, nem no âmbito de análise do Slither, nem no percurso de execução simbólica do Mythril. De acordo com o estudo comparativo da Dreamlab Technologies, o Slither e o Mythril detetaram, respetivamente, 5 em cada 10 e 6 em cada 10 vulnerabilidades no contrato testado. No entanto, estes resultados partem do princípio de que as vulnerabilidades existem no código. De acordo com uma investigação do IEEE, mesmo ao nível do código, as ferramentas existentes só conseguem detetar entre 8 % e 20 % das vulnerabilidades exploráveis.

Do ponto de vista do atual paradigma de auditoria, não existe nenhuma ferramenta capaz de «detectar se o limiar DVN é razoável». Para detetar este tipo de risco de configuração, o que é necessário não é um analisador de código, mas sim uma lista de verificação de configuração especializada: «O número de DVNs para o protocolo inter-cadeias é ≥ N?» «Existe um requisito de limiar mínimo?» Atualmente, essas questões não são abordadas por ferramentas padronizadas e não existe um padrão do setor amplamente reconhecido.

Também fazem parte da zona vermelha a segurança de chaves e de nós. Na descrição de @0xQuit, refere-se que um nó DVN foi «comprometido», o que se enquadra no âmbito da Segurança Operacional (OpSec) e está fora do alcance de deteção de qualquer ferramenta de análise estática. Quer se trate de uma empresa de auditoria de renome ou de uma ferramenta de análise baseada em IA, nenhuma delas tem a capacidade de prever se a chave privada de um operador de nó será divulgada.

Este ataque ativou simultaneamente duas zonas vermelhas na matriz.

A DVN é o mecanismo de verificação de mensagens entre cadeias da LayerZero V2, cujo nome completo é Decentralized Verifier Network. A sua filosofia de conceção consiste em delegar a tomada de decisões de segurança à camada de aplicações: cada protocolo ligado ao LayerZero pode escolher o número de nós DVN necessários para confirmar antes de permitir a passagem de uma mensagem entre cadeias.

Essa «flexibilidade» criou um leque de possibilidades.

A Kelp DAO optou pela extremidade mais à esquerda do espectro, com um sistema 1-de-1, exigindo apenas um nó DVN para a confirmação. Isto significa uma tolerância a falhas nula, uma vez que um atacante só precisa de comprometer esse único nó para falsificar qualquer mensagem entre cadeias. Em contrapartida, a Apechain, também ligada à LayerZero, configurou mais do que as duas DVNs exigidas e não foi afetada por este incidente. A declaração oficial da LayerZero afirmava: «Todas as outras aplicações continuam seguras», o que sugere que a segurança depende da configuração selecionada.

A recomendação padrão do setor é de, pelo menos, 2 em 3, o que significa que um atacante teria de comprometer dois nós DVN independentes simultaneamente para falsificar uma mensagem, aumentando a tolerância a falhas para 33%. Uma configuração de alta segurança, como a 5-de-9, pode aumentar a tolerância a falhas para 55%.

O problema é que os observadores externos e os utilizadores não conseguem ver esta configuração. Também conhecido como «suportado pela LayerZero», o backend pode variar entre 0 % e 55 % de tolerância a falhas, ambas designadas por DVN na documentação.

A experiente investidora em criptomoedas Dovey Wan, que viveu o incidente da Anyswap, afirmou diretamente na plataforma X: «O DVN da LayerZero acabou por ser um validador 1/1...» Todas as pontes entre cadeias devem ser submetidas imediatamente a uma análise de segurança exaustiva.

Em agosto de 2022, foi descoberta uma vulnerabilidade na ponte entre cadeias Nomad. Alguém reproduziu a transação inicial do ataque, fez pequenas alterações e conseguiu o seu objetivo, o que levou centenas de endereços a reproduzirem a exploração e a esvaziarem 190 milhões de dólares em poucas horas.

A análise pós-incidente realizada pela Nomad atribuiu a vulnerabilidade à «inicialização da raiz de confiança como 0x00 durante uma atualização de rotina». Trata-se de um erro de configuração que ocorreu durante a fase de implementação. A lógica de validação da prova de Merkle e o próprio código estavam corretos; o problema deveu-se a um valor inicial incorreto.

Se somarmos este incidente aos anteriores que envolveram a Nomad, as vulnerabilidades de configuração/inicialização já causaram perdas no valor aproximado de 482 milhões de dólares. Na história das explorações de pontes entre cadeias, a dimensão desta categoria rivaliza agora com a dos principais incidentes de exposição de chaves (por exemplo, Ronin 624 milhões de dólares, Harmony 100 milhões de dólares, Multichain 126 milhões de dólares, num total de cerca de 850 milhões de dólares).

No entanto, o desenvolvimento de produtos no setor da auditoria de código nunca se centrou nesta categoria de vulnerabilidades.

A maioria das discussões no setor continua a girar em torno de erros de lógica no código. Incidentes como a exploração de 326 milhões de dólares da Wormhole, resultante da contornagem da verificação de assinaturas, e a perda de 80 milhões de dólares da Qubit Finance, devido a um evento de depósito falso, são analisados em pormenor com relatórios detalhados de vulnerabilidades, referências CVE e PoCs reproduzíveis, tornando-os adequados para a formação e otimização de ferramentas de auditoria. Os problemas na camada de configuração não estão explicitamente codificados, o que dificulta a sua resolução no ciclo de produção.

Um detalhe digno de nota é o facto de os dois eventos relacionados com a configuração terem mecanismos de ativação distintos. O erro da Nomad deveu-se à definição inadvertida de um valor inicial incorreto durante uma atualização de rotina, o que constituiu um erro. Por outro lado, o incidente «1-of-1» da Kelp DAO foi uma escolha de configuração deliberada — o protocolo LayerZero não proibia essa opção e a Kelp DAO não violou nenhuma regra do protocolo. Uma escolha de configuração «adequada» e um valor inicial «errado» acabaram por conduzir ao mesmo resultado.

A lógica de execução deste ataque era simples. Uma mensagem entre cadeias falsificada informou a rede principal da Ethereum de que «alguém já tinha bloqueado um ativo equivalente noutra cadeia», o que desencadeou a emissão de rsETH na rede principal. O próprio rsETH cunhado não tinha qualquer garantia real, mas o seu registo na cadeia de blocos era «válido» e podia ser aceite pelos protocolos de empréstimo como garantia.

O atacante distribuiu então 116 500 rsETH entre a Aave V3 (Ethereum e Arbitrum), a Compound V3 e a Euler, obtendo empréstimos no valor total de 236 milhões de dólares em ativos reais. De acordo com várias fontes, a estimativa de incumprimento independente para o Aave V3 ronda os 177 milhões de dólares. O módulo de segurança da Aave, o Umbrella, utilizado para absorver perdas decorrentes de incumprimentos, dispõe de uma reserva de WETH de cerca de 50 milhões de dólares, com um rácio de cobertura inferior a 30%, devendo o montante restante ser suportado pelos participantes que apostam aWETH.

Em última análise, a responsabilidade recai sobre aqueles que apenas queriam ganhar alguns juros em WETH.

À data da redação deste artigo, a LayerZero continua a realizar uma investigação conjunta com a organização de resposta a emergências de segurança SEAL Org e planeia publicar um relatório de análise pós-incidente em colaboração com a Kelp DAO assim que todas as informações forem obtidas. A Kelp DAO afirmou que está a trabalhar numa «solução ativa».

A falha de segurança no valor de 293 milhões de dólares não está no código. A expressão «auditoria aprovada» não especificava a localização desse parâmetro.