US$ 293 milhões desapareceram, código sem nenhuma vulnerabilidade: o maior ataque cibernético de 2026 expõe pontos cegos de segurança na configuração da DVN.

Em 18 de abril de 2026, o protocolo de renegociação de liquidez da Kelp DAO foi comprometido por um atacante que desviou 116.500 rsETH da ponte entre blockchains em poucas horas, o equivalente a aproximadamente US$ 293 milhões na época. Todo o processo foi excepcionalmente eficiente, desde a falsificação de mensagens entre blockchains até a distribuição dos fundos roubados por meio de três protocolos de empréstimo — Aave V3, Compound V3 e Euler — para empréstimos de ativos reais. Os atacantes retiraram o equivalente a US$ 236 milhões em WETH no mesmo dia. Aave, SparkLend e Fluid, subsequentemente, congelaram o mercado de rsETH.

Este é o maior ataque DeFi até agora em 2026.

Mas um fator distingue este ataque da maioria dos incidentes de hackers: o código do contrato inteligente da Kelp DAO não continha vulnerabilidades. O pesquisador de segurança @0xQuit, que participou da investigação, escreveu no X: "Pelo que entendi até o momento, trata-se de uma combinação de dois problemas: uma configuração DVN 1 de 1 e o próprio nó DVN comprometido." A declaração oficial da LayerZero também não mencionou o código do contrato, caracterizando o problema como uma "vulnerabilidade do rsETH" em vez de uma "vulnerabilidade da LayerZero".

Os 293 milhões de dólares não estão em nenhuma linha de código. Estão ocultos em um parâmetro de configuração que foi inserido incorretamente durante a implantação.

A lógica geral da auditoria de segurança em DeFi é: encontrar o contrato, ler o código e encontrar vulnerabilidades. Essa lógica funciona muito bem quando se trata de vulnerabilidades na lógica do código. Ferramentas como Slither e Mythril têm capacidades relativamente maduras na detecção de padrões conhecidos, como ataques de reentrância e estouros de inteiros. A auditoria de código assistida por LLM, que tem sido bastante promovida nos últimos dois anos, também possui alguma capacidade de detectar vulnerabilidades na lógica de negócios (como caminhos de arbitragem de empréstimos relâmpago).

No entanto, existem duas linhas vermelhas nesta matriz.

Vulnerabilidades na camada de configuração representam um ponto cego estrutural na auditoria de ferramentas. O problema com o Kelp DAO não está no arquivo .sol, mas em um parâmetro escrito durante a implantação do protocolo — o limite DVN. Esse parâmetro determina quantos nós de verificação uma mensagem entre cadeias precisa confirmar para ser considerada legítima. Ele não entra no código, não está dentro do escopo de varredura do Slither nem entra no caminho de execução simbólica do Mythril. De acordo com um estudo comparativo da Dreamlab Technologies, o Slither e o Mythril detectaram 5/10 e 6/10 vulnerabilidades, respectivamente, nos contratos testados, mas essa conquista se baseia na premissa de que "as vulnerabilidades estão no código". Segundo pesquisa do IEEE, mesmo no nível do código, as ferramentas existentes conseguem detectar apenas de 8% a 20% das vulnerabilidades exploráveis.

Do ponto de vista dos paradigmas de auditoria existentes, não há ferramenta capaz de "detectar se o limite de DVN é razoável". Para detectar esse tipo de risco de configuração, o que se faz necessário não é um analisador de código, mas sim uma lista de verificação de configuração específica: "O número de DVNs usados no protocolo entre cadeias é ≥ N?", "Existe um requisito de limite mínimo?". Atualmente, não existem ferramentas padronizadas para abordar esse tipo de questão, e nem mesmo padrões da indústria amplamente reconhecidos.

A área vermelha também inclui a segurança de chaves e nós. A descrição de @0xQuit menciona um nó DVN sendo "violado", o que se enquadra na categoria de segurança operacional (OpSec) e está além da capacidade de detecção de qualquer ferramenta de análise estática. Nem as principais empresas de auditoria nem as ferramentas de varredura de IA conseguem prever se a chave privada de um operador de nó será vazada.

Este ataque desencadeou simultaneamente duas áreas vermelhas na matriz.

DVN é o mecanismo de verificação de mensagens entre cadeias do LayerZero V2, abreviação de Rede Verificadora Descentralizada. Sua filosofia de projeto é delegar o poder de decisão de segurança à camada de aplicação: cada protocolo conectado ao LayerZero pode escolher quantos nós DVN precisam confirmar simultaneamente antes de permitir que uma mensagem entre cadeias seja transmitida.

Esse "grau de liberdade" produz um espectro.

A Kelp DAO escolheu a configuração 1 de 1 mais à esquerda no espectro, exigindo apenas um nó DVN para confirmação. Isso significa tolerância zero a falhas; um atacante precisa comprometer apenas esse nó para forjar mensagens arbitrárias entre cadeias. Em contraste, a Apechain, que também se integra com a LayerZero, mas configura mais de dois DVNs necessários, não foi afetada neste incidente. A declaração oficial da LayerZero afirmou que "todos os outros aplicativos permanecem seguros", o que implica que a segurança depende da configuração escolhida.

A recomendação padrão do setor é de pelo menos 2 de 3, o que exige que os atacantes comprometam dois nós DVN independentes simultaneamente para forjar mensagens, aumentando a tolerância a falhas para 33%. Configurações de alta segurança, como 5 de 9, podem atingir uma tolerância a falhas de até 55%.

O problema é que observadores e usuários externos não conseguem ver essa configuração. Ambas são rotuladas como "Powered by LayerZero", mas a tolerância a falhas subjacente pode ser de 0% ou 55%. Ambas são referidas como DVN na documentação.

Dovey Wan, uma investidora veterana em criptomoedas que vivenciou o incidente da Anyswap, escreveu diretamente no X: "O DVN da LayerZero é um validador 1/1... Todas as pontes entre cadeias devem passar por uma revisão de segurança completa imediatamente."

Em agosto de 2022, uma vulnerabilidade foi descoberta na ponte entre blockchains Nomad. Alguém copiou a primeira transação do ataque, fez pequenas modificações e descobriu que ele era bem-sucedido — centenas de endereços começaram então a copiá-lo, drenando US$ 190 milhões em poucas horas.

A análise pós-incidente da Nomad afirmou que a vulnerabilidade se originou da "inicialização da raiz confiável com o valor 0x00 durante uma atualização de rotina". Tratava-se de um erro de configuração ocorrido durante a fase de implantação. A Merkle comprovou que a lógica de verificação estava correta, o código em si não apresentava falhas e o problema residia em um valor inicial incorreto.

Juntamente com o Nomad, as vulnerabilidades de configuração/inicialização já causaram perdas de aproximadamente US$ 482 milhões. Em toda a história de roubos de pontes entre blockchains, essa categoria é comparável em escala às violações de chaves (US$ 624 milhões para o Ronin, US$ 100 milhões para o Harmony e US$ 126 milhões para o Multichain, totalizando aproximadamente US$ 850 milhões).

No entanto, o design de produtos na indústria de auditoria de código nunca foi direcionado para essa categoria.

O tópico mais discutido no setor ainda são as vulnerabilidades na lógica do código. O prejuízo de US$ 326 milhões da Wormhole devido à violação da verificação de assinatura e o roubo de US$ 80 milhões da Qubit Finance por depósitos fraudulentos são exemplos disso. Esses casos possuem relatórios completos de análise de vulnerabilidades, comparações de números CVE e provas de conceito (PoCs) reproduzíveis, tornando-os adequados para treinamento e otimização de ferramentas de auditoria. Problemas de configuração, se não forem corrigidos no código, dificilmente serão implementados no ciclo de produção.

Um detalhe importante é que os dois eventos de configuração foram acionados de maneiras drasticamente diferentes. Nomad inseriu acidentalmente um valor inicial incorreto durante uma atualização de rotina, o que foi um erro. Já a configuração 1-de-1 do Kelp DAO foi uma escolha proativa — o protocolo LayerZero não proíbe essa opção, e o Kelp DAO não violou nenhuma regra do protocolo. Uma escolha de configuração "em conformidade" e um valor inicial "equivocado" apontam, em última análise, para a mesma consequência.

A lógica de execução deste ataque é simples: uma mensagem forjada entre cadeias informa à rede principal do Ethereum que "alguém em outra cadeia bloqueou ativos de valor equivalente", fazendo com que a rede principal emita rsETH. O rsETH emitido não possui lastro real, mas seu registro na cadeia é "legítimo" e pode ser aceito como garantia por protocolos de empréstimo.

Os atacantes então dispersaram 116.500 rsETH entre as plataformas Aave V3 (Ethereum e Arbitrum), Compound V3 e Euler, emprestando um total de mais de US$ 236 milhões em ativos reais. De acordo com diversos relatórios, somente a Aave V3 enfrenta uma dívida incobrável estimada em US$ 177 milhões. O módulo de segurança da Aave, Umbrella, possui aproximadamente US$ 50 milhões em reservas de WETH disponíveis para absorver a dívida incobrável, cobrindo menos de 30% do total; o restante será coberto pelos detentores de aWETH em staking.

Em última análise, esse ônus recai sobre aqueles que apenas queriam ganhar um pouco de juros WETH.

Até o momento da publicação desta notícia, a LayerZero ainda está conduzindo uma investigação conjunta com a organização de resposta a incidentes de segurança SEAL Org e afirmou que divulgará um relatório de análise pós-incidente com a Kelp DAO após obter todas as informações. A Kelp DAO declarou que está realizando uma "remediação proativa".

A vulnerabilidade de 293 milhões de dólares não estava no código. A frase "Auditoria aprovada" não indicava a localização desse parâmetro.