Exploit da Ponte Ethereum da Verus: O Mesmo Bug de $11.58M
Em 18 de maio de 2026, alguém drenou a bridge Verus-Ethereum em US$ 11,58 milhões. De acordo com a reportagem da CoinDesk, foi o oitavo hack de bridge do ano. O exploit da bridge Verus Ethereum não envolveu nenhuma classe de ataque exótica ou nova. Foi a mesma falha que vemos matar bridges desde 2021: o contrato liberou fundos em uma chain sem verificar corretamente o que realmente aconteceu na outra.
A função vulnerável tinha um nome desta vez. checkCCEValues. Essa é a rotina que deveria confirmar que os valores de exportação cross-chain correspondiam à realidade antes de fazer o mint ou liberar no lado Ethereum. Ela não cumpriu sua função, e o atacante foi embora com tudo.
Passei quatro anos construindo infraestrutura adjacente a bridges em um contexto regulado, e a parte deprimente é o quão previsível isso se tornou. Continuamos dando um novo nome à mesma ferida.
O exploit da bridge Verus Ethereum foi uma falha de validação de origem
Tire o branding e toda bridge faz uma coisa só. Ela observa um evento na chain A (um depósito, um bloqueio, uma exportação) e produz uma ação correspondente na chain B (um mint, um desbloqueio, uma liberação). Todo o modelo de segurança se resume a uma única pergunta: a chain B realmente acredita no que a chain A disse, e verificou isso?
Quando a validação que confirma os valores do lado de origem está errada, a resposta se torna "não." O atacante forja ou infla o valor de exportação declarado, o contrato de destino confia nele, e tokens que nunca foram lastreados são emitidos ou liberados. The Block reportou o prejuízo em aproximadamente US$ 11,58 milhões, drenados exatamente por meio desse tipo de lacuna contábil na verificação de exportação cross-chain.
Esta é a validação de valor de origem em uma bridge, e é a função mais crítica de todo o sistema. Erre em uma comparação e a bridge se torna uma impressora de dinheiro gratuita.
checkCCEValues é apenas o nome mais novo de uma vulnerabilidade antiga
A vulnerabilidade checkCCEValues é estruturalmente idêntica a bugs que já custaram bilhões ao setor. Os nomes mudam. O mecanismo não.
- Wormhole, 2022: uma brecha na verificação de assinatura permitiu que um atacante emitisse 120.000 wrapped ETH que nunca foram depositados.
- Nomad, 2022: uma inicialização incorreta da raiz merkle fez com que qualquer mensagem validasse como verdadeira, e a bridge foi copiada e colada até o colapso por uma multidão.
- Multichain, 2023: chaves e premissas de confiança que ninguém conseguia verificar de fora.
Cada um desses foi, em sua essência, a chain de destino liberando valor sem uma prova sólida do evento de origem. checkCCEValues é a grafia de 2026 para a mesma palavra.
Acho que o setor continua tratando esses casos como erros individuais de engenharia quando são uma falha de categoria. Não se corrige uma categoria auditando uma função com mais rigor.
O Tornado Cash financiou o atacante, o que diz algo sobre a intenção
A carteira do atacante foi financiada pelo Tornado Cash antes do exploit. Esse detalhe importa menos pela atribuição do que pelo que revela sobre a preparação. Não foi um pesquisador de segurança testando um contrato que se surpreendeu com o resultado. O padrão de atacante financiado pelo Tornado Cash é a assinatura de alguém que configurou cobertura operacional dias antes e esperava que os fundos precisassem de lavagem na saída.
Essa é a parte que os defensores subestimam. Quando a transação do exploit acontece, a saída já está construída. O rastreamento posterior ajuda os promotores, mas não faz quase nada pelo protocolo que acabou de perder oito dígitos.
As falhas de segurança em bridges agora são um imposto mensal
Amplie a perspectiva e o hack da Verus é um item de linha, não uma exceção. De acordo com dados da PeckShield citados pelo Bitcoin.com, os exploits de bridges de criptomoedas somaram aproximadamente US$ 328 milhões apenas em maio de 2026. Oito incidentes de bridge em menos de cinco meses do ano.
O mercado discretamente precificou isso como um custo de fazer negócios cross-chain. Essa é a lição errada. Uma perda mensal recorrente de nove dígitos não é volatilidade, é um defeito estrutural que o espaço de design se recusa a enfrentar.
Para quem movimenta valor real, a conclusão é desconfortável: a maioria das bridges são premissas de confiança usando um traje de matemática. Já argumentei antes, em Como as Bridges de Stablecoin Realmente Falham, que a bridge mais segura muitas vezes é aquela que admite o quanto pouco verifica de fato.
Como é uma verificação de bridge realmente defensável
Se você está construindo ou auditando uma bridge, a validação de valor de origem é onde você deve concentrar uma parcela desproporcional de sua paranoia. Algumas coisas que eu trataria como inegociáveis:
- O contrato de destino deve verificar uma prova criptográfica do evento de origem, não a palavra de um relayer. Provas de cliente leve ou provas zk em vez de atestações multisig onde o orçamento de latência permitir.
- As verificações de valor devem ser exaustivas em todos os caminhos. A classe de bug
checkCCEValuesgeralmente se esconde em um branch que algumas entradas pulam. Faça fuzzing na comparação, não apenas inspecione visualmente. - Limites de taxa e circuit breakers por ativo, para que um valor forjado não possa drenar toda a reserva em uma única transação. Um limite que pausa automaticamente em, digamos, 5% do TVL por hora teria atenuado a maioria dos incidentes de 2026.
- Monitoramento independente de invariantes que observa o total emitido versus o total bloqueado em tempo real e para em caso de divergência.
Nada disso é novo. A stack de auditoria para detectar esses problemas existe, o que explorei no artigo sobre a stack de auditoria. O problema é que as bridges continuam lançando a validação como um detalhe secundário em vez de como o produto.
O próximo hack de bridge de 2026 já está sendo escrito. Terá um nome de função diferente e a mesma causa raiz, e vamos fingir surpresa novamente. Não deveríamos.