O bug de $293 milhões não estava no código; então, qual é o problema com o "Bug de Configuração DVN," que levou ao maior hack de 2026?

Em 18 de abril de 2026, o protocolo de restaking de liquidez do Kelp DAO foi explorado, com o atacante desviando 116.500 rsETH de uma ponte cross-chain em poucas horas, totalizando aproximadamente $293 milhões na época. Todo o processo foi executado de forma eficiente com um toque de anomalia, começando por uma mensagem cross-chain forjada até a lavagem dos fundos roubados através dos protocolos de empréstimo Aave V3, Compound V3 e Euler com ativos reais emprestados. O atacante rapidamente saiu com $236 milhões em WETH no mesmo dia. Aave, SparkLend e Fluid congelaram prontamente o mercado de rsETH.

Isso marca o maior evento de exploração DeFi de 2026.

No entanto, um aspecto distingue este ataque da maioria dos incidentes de hacking. O código do contrato inteligente do Kelp DAO não tinha vulnerabilidades. O pesquisador de segurança @0xQuit, envolvido na investigação, afirmou no X: "Pelo que entendo atualmente, isso é uma combinação de dois problemas: uma configuração DVN 1-de-1 e a comprometimento do próprio nó DVN." Em sua declaração oficial, a LayerZero não culpou o código do contrato, categorizando o problema como uma "vulnerabilidade rsETH" em vez de uma "vulnerabilidade LayerZero."

$293 milhões não estava em nenhuma linha de código. Estava oculto dentro de um parâmetro mal configurado durante a implantação.

A lógica comum por trás das auditorias de segurança DeFi é: encontrar o contrato, ler o código, encontrar vulnerabilidades. Essa lógica opera de forma bastante suave ao lidar com vulnerabilidades de lógica de código. Ferramentas como Slither e Mythril são maduras na detecção de padrões conhecidos, como ataques de reentrância e estouros de inteiros. O LLM amplamente promovido para auxiliar em auditorias de código também possui alguma capacidade de identificar vulnerabilidades de lógica de negócios (por exemplo, caminhos de arbitragem de empréstimos relâmpago).

No entanto, nesta matriz, duas linhas estão marcadas em vermelho.

Vulnerabilidades em nível de configuração caem em um ponto cego estrutural em auditorias baseadas em ferramentas. O problema com o Kelp DAO não estava em um arquivo .sol, mas em um parâmetro—limite de DVN—escrito durante a implantação do protocolo. Esse parâmetro determina quantos nós validadores uma mensagem cross-chain deve passar para ser considerada válida. Não está no código, nem dentro do escopo de varredura do Slither, nem no caminho de execução simbólica do Mythril. De acordo com o estudo comparativo da Dreamlab Technologies, o Slither e o Mythril detectaram, respectivamente, 5/10 e 6/10 vulnerabilidades no contrato testado. No entanto, esses resultados são baseados na premissa de que as vulnerabilidades existem no código. Segundo uma pesquisa da IEEE, mesmo a nível de código, as ferramentas existentes só conseguem detectar de 8% a 20% das vulnerabilidades exploráveis.

Do ponto de vista do atual paradigma de auditoria, não existe ferramenta que possa "detectar se o limite de DVN é razoável." Para detectar esse tipo de risco de configuração, o que é necessário não é um analisador de código, mas uma lista de verificação de configuração especializada: "O número de DVNs para o protocolo cross-chain é ≥ N?" "Há um requisito mínimo de limite?" Essas perguntas atualmente não são cobertas por ferramentas padronizadas e não há um padrão amplamente reconhecido na indústria.

Também dentro da zona vermelha está a segurança de chaves e nós. Na descrição de @0xQuit, é mencionado que um nó DVN foi "comprometido," o que se enquadra na Segurança Operacional (OpSec) e está além do limite de detecção de qualquer ferramenta de análise estática. Seja uma empresa de auditoria de primeira linha ou uma ferramenta de varredura de IA, nenhuma tem a capacidade de prever se a chave privada de um operador de nó será vazada.

Esse ataque acionou simultaneamente duas zonas vermelhas na matriz.

DVN é o mecanismo de verificação de mensagens cross-chain do LayerZero V2, cujo nome completo é Rede de Verificadores Descentralizados. Sua filosofia de design é confiar a tomada de decisões de segurança à camada de aplicação: cada protocolo que se conecta ao LayerZero pode escolher o número de nós DVN necessários para confirmar antes de permitir que uma mensagem cross-chain passe.

Essa "flexibilidade" criou um espectro.

O Kelp DAO escolheu a extremidade mais à esquerda do espectro com um 1-de-1, exigindo apenas um nó DVN para confirmar. Isso significa uma tolerância a falhas de zero, já que um atacante precisa apenas comprometer aquele único nó para forjar qualquer mensagem cross-chain. Em contraste, a Apechain, também conectada ao LayerZero, configurou mais de dois DVNs necessários e não foi afetada por esse evento. A redação na declaração oficial da LayerZero foi: "Todos os outros aplicativos permanecem seguros", implicando que a segurança depende da configuração selecionada.

A recomendação padrão da indústria é de pelo menos 2 de 3, onde um atacante precisaria comprometer dois nós DVN independentes simultaneamente para forjar uma mensagem, aumentando a tolerância a falhas para 33%. Uma configuração de alta segurança como 5 de 9 pode elevar a tolerância a falhas para 55%.

O problema é que observadores externos e usuários não conseguem ver essa configuração. Também conhecido como "suportado pela LayerZero", o backend pode variar de 0% a 55% de tolerância a falhas, ambos referidos como DVN na documentação.

A experiente investidora em criptomoedas Dovey Wan, que vivenciou o incidente do Anyswap, declarou diretamente na plataforma X: "O DVN da LayerZero acabou sendo um validador 1/1... Todas as pontes cross-chain devem imediatamente passar por uma revisão de segurança abrangente."

Em agosto de 2022, uma vulnerabilidade foi descoberta na ponte cross-chain Nomad. Alguém replicou a transação de ataque inicial, fez pequenas modificações e obteve sucesso, levando centenas de endereços a replicar a exploração e drenando $190 milhões em poucas horas.

A análise post-mortem da Nomad atribuiu a vulnerabilidade a "inicializar a raiz confiável como 0x00 durante uma atualização de rotina." Esse foi um erro de configuração que ocorreu durante a fase de implantação. A lógica de validação da prova Merkle e o código em si eram sólidos; o problema surgiu de um valor inicial incorreto.

Combinando este incidente com os anteriores envolvendo a Nomad, vulnerabilidades de configuração/inicialização resultaram agora em aproximadamente $482 milhões em perdas. Na história das explorações de pontes cross-chain, a escala desta categoria agora rivaliza a de incidentes de exposição de chaves (por exemplo, Ronin $624 milhões, Harmony $100 milhões, Multichain $126 milhões, totalizando cerca de $850 milhões).

No entanto, o design do produto da indústria de auditoria de código nunca se concentrou nesta categoria de vulnerabilidades.

A maioria das discussões na indústria ainda gira em torno de bugs de lógica de código. Incidentes como a exploração de $326 milhões do Wormhole devido à bypass de verificação de assinatura e a perda de $80 milhões da Qubit Finance devido a um evento de depósito falso são bem analisados com relatórios de vulnerabilidade detalhados, referências CVE e PoCs reproduzíveis, tornando-os adequados para treinamento e otimização de ferramentas de auditoria. Problemas na camada de configuração não são explicitamente codificados, tornando desafiador abordá-los dentro do ciclo de produção.

Um detalhe notável é os distintos mecanismos de acionamento dos dois eventos relacionados à configuração. O erro do Nomad decorreu de definir inadvertidamente um valor inicial incorreto durante uma atualização de rotina, constituindo um erro. Por outro lado, o incidente 1-de-1 do Kelp DAO foi uma escolha de configuração ativa—o protocolo LayerZero não proibiu essa opção, e o Kelp DAO não violou nenhuma regra do protocolo. Uma escolha de configuração "compliant" e um valor inicial "errado" levaram ao mesmo resultado no final.

A lógica de execução deste ataque era direta. Uma mensagem forjada entre cadeias informou a rede principal do Ethereum que "alguém já havia bloqueado um ativo equivalente em outra cadeia," acionando a cunhagem de rsETH na rede principal. O rsETH cunhado em si não tinha lastro real, mas seu registro na cadeia era "válido" e poderia ser aceito por protocolos de empréstimo como colateral.

O atacante então dispersou 116.500 rsETH para Aave V3 (Ethereum e Arbitrum), Compound V3 e Euler, tomando emprestado mais de um total de $236 milhões em ativos reais. De acordo com várias fontes, a estimativa padrão autônoma para Aave V3 é de cerca de $177 milhões. O módulo de segurança da Aave, Umbrella, usado para absorver perdas por inadimplência, possui uma reserva de WETH de cerca de $50 milhões com uma razão de cobertura de menos de 30%, com o valor restante a ser suportado pelos stakers de aWETH.

Isso, em última análise, recai sobre aqueles que simplesmente queriam ganhar algum rendimento em WETH.

No momento da redação, o LayerZero ainda está conduzindo uma investigação conjunta com a organização de resposta a emergências de segurança SEAL Org e planeja liberar um relatório de análise pós-incidente em colaboração com o Kelp DAO assim que todas as informações forem obtidas. O Kelp DAO declarou que está trabalhando em "remediação ativa."

A exploração de $293 milhões não está no código. A frase "auditoria aprovada" não cobriu a localização desse parâmetro.