Saltar para o conteúdo principal

$ 606 milhões em 18 dias: Por que bugs introduzidos por atualizações são o novo principal vetor de ataque do DeFi

· 14 min de leitura
Dora Noda
Software Engineer

Em apenas 18 dias neste mês de abril, atacantes drenaram $ 606 milhões do setor DeFi. Esse único período apagou as perdas do primeiro trimestre de 2026 em 3,7 vezes e tornou o mês o pior desde o assalto à Bybit em fevereiro de 2025. Dois protocolos — Drift na Solana e Kelp DAO na Ethereum — foram responsáveis por 95 % dos danos. Ambos haviam sido auditados. Ambos passaram por análises estáticas. Ambos lançaram atualizações de rotina que silenciosamente invalidaram as premissas que seus auditores haviam verificado.

Este é o novo rosto do risco DeFi. Os exploits catastróficos de 2026 não são mais sobre bugs de reentrância ou estouros de inteiros que ferramentas de fuzzing podem detectar em CI. Eles tratam de vulnerabilidades introduzidas por atualizações: mudanças sutis em configurações de pontes, fontes de oráculos, funções de administrador ou padrões de mensagens que transformam códigos anteriormente seguros em uma porta aberta — sem que nenhuma linha individual de Solidity pareça obviamente errada.

Se você constrói, faz custódia ou simplesmente detém ativos em DeFi, a conclusão de abril de 2026 é desconfortável: um relatório de auditoria limpo datado de três meses atrás não é mais evidência de que um protocolo é seguro hoje.

O Padrão de Abril: Configuração, Não Código

Para entender por que "introduzido por atualização" merece sua própria categoria, observe como os dois maiores exploits realmente ocorreram.

**Drift Protocol — 285milho~es,1deabrilde2026.AmaiorDEXdeperpeˊtuosdaSolanaperdeumaisdametadedoseuTVLapoˊsatacantespassaremseismesesexecutandoumacampanhadeengenhariasocialcontraaequipe.Assimqueaconfianc\cafoiestabelecida,elesusaramorecursode"noncesduraˊveis"daSolanaumaconvenie^nciadeUXprojetadaparapermitirqueusuaˊriospreˊassinemtransac\co~esparasubmissa~oposteriorparaenganarmembrosdoConselhodeSeguranc\cadaDriftaautorizaremoquepensavamserassinaturasoperacionaisderotina.Essasassinaturaseventualmenteentregaramocontroleadministrativoaosatacantes,quelistaramumtokendecolateralfalso(CVT),depositaram500milho~esdeunidadesdeleeretiraram285 milhões, 1 de abril de 2026.** A maior DEX de perpétuos da Solana perdeu mais da metade do seu TVL após atacantes passarem seis meses executando uma campanha de engenharia social contra a equipe. Assim que a confiança foi estabelecida, eles usaram o recurso de "nonces duráveis" da Solana — uma conveniência de UX projetada para permitir que usuários pré-assinem transações para submissão posterior — para enganar membros do Conselho de Segurança da Drift a autorizarem o que pensavam ser assinaturas operacionais de rotina. Essas assinaturas eventualmente entregaram o controle administrativo aos atacantes, que listaram um token de colateral falso (CVT), depositaram 500 milhões de unidades dele e retiraram 285 milhões em USDC, SOL e ETH reais. O recurso da Solana estava funcionando conforme projetado. Os contratos da Drift estavam fazendo o que seus administradores instruíram. O ataque viveu inteiramente na lacuna entre o que os signatários do multisig pensavam que estavam aprovando e o que realmente estavam.

Kelp DAO — $ 292 milhões, 18 de abril de 2026. Atacantes atribuídos pela LayerZero ao Lazarus Group da Coreia do Norte comprometeram dois nós RPC que sustentavam a ponte rsETH cross-chain da Kelp, trocaram os binários que rodavam neles e usaram um DDoS para forçar um failover de verificador. Os nós maliciosos então informaram ao verificador da LayerZero que uma transação fraudulenta havia ocorrido. O exploit só funcionou porque a Kelp operava uma configuração de verificador 1-de-1 — o que significa que uma única DVN operada pela LayerZero tinha autoridade unilateral para confirmar mensagens cross-chain. De acordo com a LayerZero, essa configuração 1-de-1 é o padrão em seu guia de início rápido e é usada atualmente por aproximadamente 40 % dos protocolos na rede. Em 46 minutos, um atacante drenou 116.500 rsETH — cerca de 18 % de todo o suprimento circulante — e isolou colaterais embrulhados em 20 chains. A Aave, que lista rsETH, foi forçada a uma crise de liquidez enquanto os depositantes corriam para a saída.

Nenhum dos ataques exigiu um bug de contrato inteligente. Ambos exigiram entender como uma configuração — fluxos de assinatura multisig, contagem padrão de DVNs, redundância de RPC — foi silenciosamente elevada de "detalhe operacional" para "premissa de segurança estrutural".

Por Que Auditorias Estáticas Ignoram Esta Classe de Bug

A auditoria tradicional de DeFi é otimizada para o modelo de ameaça errado. Empresas como Certik, OpenZeppelin, Trail of Bits e Halborn se destacam na revisão de código linha por linha e na execução de testes de invariantes contra uma versão de contrato congelada. Isso captura reentrância, erros de controle de acesso, estouros de inteiros e falhas do tipo OWASP.

But a classe de bugs introduzidos por atualizações possui três propriedades que derrotam esse fluxo de trabalho:

  1. Vive no comportamento de execução composto, não no código-fonte. A segurança de uma ponte depende da configuração do verificador de sua camada de mensagens, do conjunto de DVNs, da redundância de RPC dessas DVNs e da exposição ao slashing desses operadores. Nada disso está no Solidity que um auditor lê.

  2. É introduzido por mudanças, não pela implantação inicial. A ponte da Kelp presumivelmente parecia correta quando a LayerZero v2 foi integrada pela primeira vez. A contagem de DVNs tornou-se perigosa apenas à medida que o TVL cresceu o suficiente para valer a pena atacar e quando o Lazarus investiu no comprometimento da infraestrutura de RPC.

  3. Exige testes diferenciais comportamentais — respondendo "o invariante X foi preservado sob o novo caminho de código?" — o que nenhuma das principais empresas de auditoria transforma em um serviço pós-atualização programado. Você recebe uma auditoria pontual na versão 1.0 e uma auditoria pontual separada na versão 1.1, mas nenhuma afirmação contínua de que atualizar da 1.0 para a 1.1 não quebra propriedades nas quais a 1.0 dependia.

As estatísticas do primeiro trimestre de 2026 quantificam essa lacuna. O DeFi registrou 165,5milho~esemperdasem34incidentesemtodootrimestre.Apenasabrilproduziu165,5 milhões em perdas em 34 incidentes em todo o trimestre. Apenas abril produziu 606 milhões em 12 incidentes. O lado da implantação escalou — mais de $ 40 bilhões em novo TVL foram adicionados no primeiro trimestre — enquanto a capacidade de auditoria, a resposta a incidentes e a validação pós-implantação permaneceram praticamente estáveis. Algo tinha que ceder.

Três Forças Que Tornam 2026 o Ano em Que Isso se Torna Crítico em Escala

1. A cadência de atualizações acelerou em todas as camadas

Cada L1 e L2 está iterando mais rapidamente. A atualização Pectra do Ethereum está em implementação ativa, Fusaka e Glamsterdam estão em fase de design, e Solana, Sui e Aptos lançam mudanças na camada de execução em ciclos de várias semanas. Cada atualização no nível da blockchain pode alterar sutilmente a semântica de gas, os esquemas de assinatura ou a ordenação de transações de formas que impactam as suposições da camada de aplicação. O exploit da Drift é um exemplo claro — um recurso da Solana (nonces duráveis) destinado à conveniência da experiência do usuário (UX) tornou-se o vetor para uma invasão administrativa.

2. O restaking amplia a superfície de ataque das atualizações

A stack de restaking — EigenLayer (ainda com mais de 80 % do mercado), Symbiotic, Karak, Babylon, Solayer — adiciona uma terceira dimensão ao problema. Um único LRT como o rsETH está posicionado acima da EigenLayer, que por sua vez está acima do staking nativo de ETH. Cada camada lança suas próprias atualizações em seu próprio cronograma. Uma mudança na semântica de slashing da EigenLayer tem consequências implícitas para cada operador e cada LRT que consome a validação desse operador. Quando a ponte da Kelp foi drenada, o contágio ameaçou imediatamente o TVL da EigenLayer, porque os mesmos depositantes tinham uma exposição de re-hipotecagem de três camadas que nunca haviam sido forçados a modelar. O roadmap da EigenCloud, com suas expansões iminentes de EigenDA, EigenCompute e EigenVerify, apenas ampliará essa superfície.

3. A atividade de DeFi impulsionada por IA move-se mais rápido que a revisão humana

Stacks de agentes como XION, Brahma Console e Giza agora interagem com contratos atualizados na velocidade das máquinas. Enquanto um tesoureiro humano pode esperar dias após a atualização de um contrato antes de interagir novamente, um agente realiza backtests, integra-o e roteia capital através dele em poucas horas. Qualquer atualização que quebre silenciosamente um invariante é testada sob estresse por fluxos adversariais antes que um auditor humano possa revisá-la.

A Arquitetura Defensiva Começa a Surgir

A notícia encorajadora é que a comunidade de pesquisa em segurança não tem estado ociosa. As perdas de abril de 2026 catalisaram propostas concretas em quatro frentes.

Verificação formal contínua. A colaboração de longa data da Certora com a Aave — financiada como uma concessão de verificação contínua em vez de um compromisso único — é agora um modelo. O Certora Prover executa automaticamente provas de invariantes toda vez que um contrato é alterado, revelando falhas antes do merge. Halmos e HEVM oferecem caminhos alternativos de código aberto para o mesmo objetivo. Quando a verificação formal capturou recentemente uma vulnerabilidade em uma integração com a atualização Electra do Ethereum que as auditorias tradicionais haviam perdido, não foi um caso isolado; foi uma prévia.

Serviços de auditoria de diff de atualização. Spearbit, Zellic e Cantina começaram a pilotar serviços pagos que auditam o diff entre duas versões de contrato, não a nova versão isoladamente. O modelo trata cada atualização como uma nova atestação e examina explicitamente se os invariantes anteriores são preservados. O programa de subsídio de auditoria de $ 1 milhão da Fundação Ethereum, lançado em 14 de abril de 2026, com uma lista de parceiros que inclui Certora, Cyfrin, Dedaub, Hacken, Immunefi, Quantstamp, Sherlock, Spearbit, Zellic e Zokyo, visa em parte expandir a capacidade para exatamente este tipo de trabalho.

Engenharia de caos e monitoramento em tempo de execução. OpenZeppelin Defender e ferramentas emergentes estão integrando simulações de mainnet bifurcada (forked) em pipelines de CI, permitindo que os protocolos repliquem cenários adversariais contra cada atualização proposta. A disciplina é emprestada diretamente das práticas de SRE da Web2 — e já deveria ter chegado ao DeFi há muito tempo.

Custódias de atualização com bloqueio de tempo (Timelocks). O padrão Compound Timelock v3, onde cada atualização aprovada pela governança permanece em uma fila pública por um atraso fixo antes da execução, dá à comunidade tempo para identificar problemas que a revisão interna perdeu. Isso não evita bugs introduzidos por atualizações, mas ganha tempo para que sejam descobertos antes da exploração.

A Comparação com TradFi: Auditoria Contínua é a Norma Fora do DeFi

As finanças tradicionais resolveram o problema análogo décadas atrás. O SOC 2 Type II, o padrão ao qual a maioria dos provedores de serviços institucionais é submetida, não é uma atestação única; é uma janela de auditoria contínua de seis a doze meses. O framework de risco de contraparte de Basileia III exige que os bancos atualizem seus modelos de capital à medida que as exposições mudam, não anualmente. Um banco de custódia que atualizasse um sistema de liquidação não teria permissão para operar com base em "auditamos a v1; a v2 foi apenas uma pequena mudança".

A cultura predominante no DeFi — "audite uma vez, implante para sempre, re-audite apenas em grandes reescritas" — é a prática que a TradFi rejeitou explicitamente após a crise de 2008. Na taxa de perda atual, a indústria está a caminho de $ 2 bilhões ou mais em perdas anuais por exploits de atualização. Isso é grande o suficiente para atrair reguladores que já veem os padrões de auditoria DeFi como insuficientes, e é grande o suficiente para tornar a validação contínua uma pré-condição para o capital institucional.

O Que Isso Significa para Construtores, Depositantes e Infraestrutura

Para as equipes de protocolo, o mandato operacional é direto, mesmo que não seja barato: cada atualização deve ser tratada como um novo lançamento que re-deriva, e não herda, suas garantias de segurança. Isso significa re-auditorias programadas com base em diffs, especificações de verificação formal que acompanham cada proposta de governança e bloqueios de tempo (timelocks) significativos antes da execução. Significa publicar — ao estilo da Aave — um framework de risco em cascata quantificado que nomeie em quais protocolos você depende e como é sua exposição quando um deles falha.

Para os depositantes, a lição é que "este protocolo foi auditado" não é mais um sinal útil por si só. A pergunta correta é "quando foi a última execução de verificação contínua, contra quais invariantes e em qual versão do código implantado?". Protocolos que não conseguem responder a isso devem ter seus riscos precificados de acordo.

Para provedores de infraestrutura — operadores de RPC, indexadores, custodiantes — o incidente da Kelp é um aviso direto. O comprometimento ocorreu em dois nós de RPC cujos binários foram trocados silenciosamente. Qualquer pessoa que execute infraestrutura que participe da verificação cross-chain (DVNs, nós de oráculo, sequenciadores) agora faz parte do modelo de segurança, quer tenha se inscrito para isso ou não. Compilações reproduzíveis, binários atestados, quóruns multi-operadores acima dos padrões 1-de-1 e verificação de binários assinados na inicialização não são mais opcionais.

Atualizações no nível da blockchain — Pectra e Fusaka no Ethereum, lançamentos de execução paralela em Solana e Aptos, metas de rendimento de Glamsterdam — continuarão a ampliar a superfície. Os protocolos e operadores de infraestrutura que sobreviverem a 2026 serão aqueles que adotaram a validação contínua cedo o suficiente para que sua próxima atualização de rotina seja também seu próximo checkpoint de segurança comprovável.

A BlockEden.xyz opera infraestrutura de produção de RPC, indexadores e nós em Sui, Aptos, Ethereum, Solana e uma dezena de outras blockchains. Tratamos cada atualização de protocolo — na camada da blockchain ou na camada da aplicação — como um novo evento de segurança, não como uma tarefa de manutenção. Explore nossa infraestrutura empresarial para construir sobre uma base projetada para sobreviver à cadência de atualizações que temos pela frente.

Fontes