O Bug da ZetaChain Foi Relatado por um White Hat, Descartado como "Esperado" e Posteriormente Gerou uma Exploração de US$ 334 mil
O Bug da ZetaChain Foi Relatado por um White Hat, Descartado como "Esperado" e Posteriormente Gerou uma Exploração de US$ 334 mil
No final de abril de 2026, a infraestrutura cross-chain provou mais uma vez como pequenas suposições de design podem se agravar em riscos desproporcionais. A ZetaChain confirmou que um atacante drenou aproximadamente US$ 334.000 de carteiras controladas pelo protocolo através de um conjunto encadeado de fraquezas que abrangeram a iniciação de mensagens, regras de execução na cadeia de destino e permissões de longo prazo no ERC-20. Os fundos dos usuários não foram impactados, mas o incidente ainda serve como um lembrete contundente: em sistemas cross-chain, componentes de "baixo risco" raramente permanecem de baixo risco quando interagem.
O que torna este caso especialmente instrutivo é a falha de processo por trás da falha técnica. A ZetaChain reconheceu que a questão central havia sido relatada anteriormente através de seu canal de recompensa por bugs, mas foi inicialmente tratada como comportamento pretendido, em vez de algo que exigisse mitigação ou restrições mais rigorosas. Cobertura da divulgação e detalhes pós-incidente podem ser encontrados em reportagens como o resumo da Cointelegraph sobre o relatório rejeitado e a exploração subsequente: ZetaChain rejeitou um relatório de bug que poderia ter evitado a exploração.
Abaixo está uma análise amigável para operadores do que aconteceu, por que o caminho da exploração funcionou, o que a ZetaChain mudou e o que construtores e usuários devem reter em 2026 - quando a atividade cross-chain é mais ampla do que nunca e os manuais do atacante são cada vez mais "multivetoria por padrão".
Instantâneo do Incidente: a dívida de design cross-chain vence
As ações do atacante resultaram, em última análise, em 9 transações abrangendo Ethereum, Arbitrum, Base e BNB Smart Chain, com ativos roubados originários de carteiras controladas pela ZetaChain em vez de usuários finais. A ZetaChain pausou as operações cross-chain enquanto a questão era contida; a paralisação inicial foi amplamente noticiada quando o incidente surgiu pela primeira vez publicamente (ver: Relatório do The Block sobre a paralisação e mitigação).
Embora o valor em dólar não tenha sido na escala de "mega-hack de ponte", o padrão é o que importa: um gateway cross-chain que pode ser influenciado a produzir chamadas assinadas pelo protocolo em cadeias externas é um alvo de alta alavancagem, mesmo quando o conjunto imediato de vítimas é limitado.
A Lição Desconfortável: "Comportamento Esperado" Ainda Pode Ser Comportamento Explorável
Programas de recompensa por bugs são feitos para converter curiosidade adversarial em melhoria defensiva - mas apenas se a triagem for construída para reconhecer o risco de composibilidade.
A ZetaChain lançou anteriormente seu programa de recompensas em parceria com a Immunefi (background: Anúncio do programa de recompensa por bugs da ZetaChain). No entanto, este incidente destaca um desafio recorrente na indústria: um relatório pode ser "correto" mesmo que cada componente individual pareça não crítico em isolamento. A própria Immunefi enfatiza que o impacto no mundo real e as definições de escopo são importantes (ver: Orientação da Immunefi sobre regras e impacto do programa).
Para protocolos cross-chain, a barra deve ser mais alta: se um recurso permite qualquer caminho para "o protocolo pode ser enganado para assinar algo que não deveria", então ele merece defesa em profundidade - mesmo que o recurso esteja tecnicamente funcionando como projetado.
Como Três Questões "Pequenas" Se Combinaram em Uma Grande Exploração
Uma análise técnica detalhada do fluxo de chamadas e do comportamento do contrato foi publicada por pesquisadores independentes; uma das análises passo a passo mais claras é: Análise de hack do Gateway da ZetaChain.
Do ponto de vista do design de segurança, a cadeia de exploração pode ser resumida em três elos:
1) Iniciação de Instrução Cross-Chain Permissiva na Camada de Gateway
Uma questão central foi que um caminho do lado do gateway poderia ser invocado de uma maneira que permitiu a um atacante injetar intenção cross-chain (ou seja, "enviar esta mensagem/chamada para a cadeia de destino") sem que o sistema impusesse o limite de confiança esperado para quem tem permissão para originar tais instruções.
Em sistemas cross-chain, quem tem permissão para emitir um sinal "isso deve ser executado remotamente" é a primeira e mais importante linha de defesa.
2) Regras de Execução de Destino Excessivamente Permissivas (e Excessivamente Dependentes de uma Lista Negra Restrita)
Do lado do recebimento, o caminho de execução permitiu chamadas que eram efetivamente de natureza "arbitrária", com restrições que não eram amplas o suficiente para bloquear operações perigosas de tokens. Uma lista negra que bloqueia apenas alguns seletores raramente é suficiente quando a área de superfície da EVM é enorme - e quando os atacantes só precisam de um primitivo permitido (como transferFrom) para monetizar.
Este é um modo de falha comum: listas negras envelhecem mal em ambientes adversários.
3) Permissões de ERC-20 Desatualizadas Transformaram "Execução" em "Movimentação de Ativos"
O elo final foi operacional, em vez de puramente de código: algumas carteiras mantiveram aprovações ilimitadas (ou permissões excessivas de outra forma) para o contrato de gateway e não as removeram depois de não serem mais necessárias.
No ERC-20, uma permissão é efetivamente uma permissão permanente. Uma vez que um contrato ganha a capacidade de fazer uma chamada de token como ele mesmo, qualquer permissão restante se torna uma arma carregada. Para contexto sobre como as aprovações funcionam no nível padrão, consulte: Documentação ERC-20 da OpenZeppelin.
Pesquisas também mostraram o quão generalizadas são as aprovações ilimitadas - e por que elas criam risco sistêmico - bem além de qualquer protocolo único (ver: Estudo de risco de aprovação "Economizando um centavo e gastando um tostão").
Ofício do Atacante: Não Oportunista, Mas Planejado
A ZetaChain descreveu a exploração como mostrando sinais claros de planejamento, incluindo:
- Pré-financiamento via Tornado Cash dias antes
- Implantação de um contrato "drainer" dedicado
- Execução de uma campanha de envenenamento de endereço
O envenenamento de endereço merece atenção especial porque está cada vez mais misturado a operações de exploração mais amplas - não apenas como um golpe de varejo, mas também como uma maneira de criar confusão durante a resposta a incidentes. Se você deseja uma visão geral rigorosa da técnica e por que ela funciona tão frequentemente, pesquisadores da Carnegie Mellon mantêm um recurso dedicado aqui: Visão geral do envenenamento de endereços de blockchain.
O Que a ZetaChain Mudou: Removendo Armadilhas, Não Apenas Corrigindo Bugs
As correções pós-incidente importam mais quando reduzem o risco de classe em vez de apenas bloquear um payload observado. Com base na direção de remediação divulgada pela ZetaChain (conforme resumido em relatórios públicos e análises técnicas), as principais mudanças incluem:
- Implantação de patches na infraestrutura mainnet para fechar o caminho explorado.
- Desabilitação permanente da capacidade de chamadas arbitrárias que tornou possível o resultado de "executar quaisquer calldata que o protocolo assine".
- Substituição de padrões de aprovação ilimitada em fluxos de depósito por aprovações de valor exato, para que uma única aprovação não possa permanecer silenciosamente utilizável meses depois.
O tema mais importante é a mudança de "generalidade poderosa, mas perigosa" para "intenção estreita e verificável". Protocolos cross-chain que desejam escalar com segurança em 2026 precisarão cada vez mais usar por padrão alvos permitidos, mensagens tipadas e execução com capacidade limitada.
Conclusões para Construtores: A Segurança Cross-Chain em 2026 é Sobre Composição, Não Componentes
Mesmo fora da ZetaChain, os sistemas cross-chain continuam a ser atacados porque residem na interseção de:
- Máquinas de estado complexas,
- Assinatura/validação distribuídas,
- E interfaces de token altamente monetizáveis.
Relatórios de perdas da indústria continuam a demonstrar que a gravidade da exploração permanece alta e eventos de risco de cauda dominam os resultados (ver um exemplo de rastreamento agregado da indústria em: Relatório da Immunefi "Perdas de Cripto no Q1 2025" (PDF)).
Se você estiver projetando ou integrando mensagens cross-chain, considere estas salvaguardas práticas:
- Torne a origem da mensagem explícita e autenticada: "Qualquer um pode solicitar uma chamada cross-chain" nunca deve ser equivalente a "o protocolo a assinará e executará".
- Evite listas negras para destinos de execução: prefira listas permitidas e interfaces mínimas.
- Trate permissões como parte do seu modelo de ameaça: as carteiras do tesouro / operador devem ter políticas de aprovação rigorosas, monitoramento e limpeza periódica.
- Planeje a coordenação de emergência: redes de resposta a incidentes como SEAL 911 existem porque os minutos importam quando as assinaturas e a execução cross-chain estão envolvidas.
Lista de Verificação para Usuários: O Que Fazer Após Qualquer Incidente Cross-Chain (Mesmo Que "Usuários Não Foram Afetados")
Mesmo quando um protocolo afirma que os fundos dos usuários não foram impactados, é racional dedicar 10 minutos para reduzir seu raio de explosão pessoal - especialmente se você já interagiu com os contratos de gateway afetados.
1) Revogue permissões que você não precisa ativamente
Duas opções confiáveis:
- Use uma ferramenta de gerenciamento de aprovações, como Guia de aprovação de tokens da Revoke.cash
- Ou use o verificador integrado de um explorador de blocos, como Verificador de Aprovações de Token do Etherscan
2) Defenda-se contra o envenenamento de endereço no comportamento diário
- Não copie destinatários do histórico de transações.
- Use livros de endereços / contatos confiáveis sempre que possível.
- Verifique mais do que os primeiros/últimos caracteres - ataques de envenenamento são projetados para corresponder ao que as UIs de carteira truncam.
3) Use verificação de endereço baseada em hardware para transferências de alto valor
Uma carteira de hardware não pode impedir um bug de contrato inteligente em um protocolo que você não controla - mas pode reduzir a chance de você autorizar pessoalmente o destinatário errado durante um cenário de envenenamento de endereço ou manipulação da área de transferência.
É aqui que a OneKey se encaixa naturalmente: ao manter a assinatura isolada e enfatizar a verificação no dispositivo, ela ajuda a tornar "o que você assina" mais próximo de "o que você pretende" - especialmente durante momentos de estresse quando os atacantes tentam explorar a confusão.
Pensamentos Finais
A exploração da ZetaChain é um estudo de caso compacto da realidade da segurança cripto moderna:
- uma questão previamente relatada,
- descartada devido a uma suposição "por design",
- combinada com execução permissiva e permissões remanescentes,
- executada por um atacante que preparou financiamento, ferramentas e ruído de camada social com antecedência.
Se 2025-2026 ensinou algo à indústria, é que os sistemas cross-chain devem ser projetados para composição adversarial. O recurso mais seguro é aquele que você não pode acidentalmente transformar em um oráculo de assinatura - mesmo quando tudo está "funcionando como esperado".
