Gnosis Pay: o bug já estava corrigido no GitHub

O bug que drenou cerca de 265.000 dólares da Gnosis Pay em 1 de junho de 2026 já estava corrigido no código-fonte desde 27 de fevereiro. O patch existia, estava mergeado, era público e verificável no GitHub. O que falhou não foi a detecção da falha, mas a sua propagação: o contrato implantado na rede nunca recebeu a correção porque continuava compilado contra uma dependência antiga. Este artigo não é apenas mais um relatório de hack em DeFi. É um estudo de caso de um padrão estrutural que quase ninguém audita: o abismo entre o «bug corrigido no repositório» e o «bug vivo on-chain». O módulo afetado, o Zodiac Delay Module (um módulo de governança que impõe um atraso obrigatório entre a aprovação de uma transação e sua execução, para dar margem a vetos), é open-source, está auditado e é usado por dezenas de protocolos. E, ainda assim, o código que protegia os fundos não era o código que rodava na blockchain. Vamos reconstruir a cronologia exata, explicar por que «open-source e auditado» não implica «seguro em produção» e fornecer um checklist acionável para verificar se o contrato implantado incorpora realmente os últimos patches.

O que aconteceu exatamente em 1 de junho?

Em 1 de junho de 2026, a Gnosis Pay — o cartão de débito autocustodiado que gasta saldo diretamente de uma Safe (wallet de contrato inteligente multifirma) do usuário — detectou um exploit ativo contra o Zodiac Delay Module v1.1.0 implantado na Gnosis Chain. O atacante drenou cerca de 265.000 dólares distribuídos entre várias vítimas antes que a equipe coordenasse com os validadores da bridge para pausar as operações e conter a movimentação de fundos.

A mecânica do módulo é, no papel, uma camada de proteção. Quando um usuário deseja mover fundos fora do fluxo normal de pagamento com cartão, a transação entra em uma fila e deve aguardar um período de resfriamento (cooldown) antes de ser executada. Durante esse intervalo, uma transação maliciosa pode ser marcada como inválida e vetada. É o equivalente a uma transferência bancária agendada que você pode cancelar dentro de uma janela de segurança. O Delay Module converte essa janela em código.

O exploit não quebrou a lógica do atraso de forma frontal. Ele atacou a verificação de assinaturas. O Delay Module — como boa parte do ecossistema Safe — valida certas operações por meio do padrão ERC-1271 (o mecanismo pelo qual um contrato inteligente, e não apenas uma chave privada, pode «assinar» e autorizar uma ação). A falha permitia que uma chamada de contrato que tivesse revertido (ou seja, que tivesse falhado) fosse interpretada igualmente como uma assinatura válida. O atacante controlava os dados retornados por essa chamada falha e, com eles, fabricava uma autorização que o módulo aceitava como legítima.

Por que uma falha de 2023 detonou em 2026?

Aqui começa o ponto interessante, onde a cronologia deixa de ser um relatório de incidente para se tornar um estudo de caso. O bug não nasceu em junho de 2026. De acordo com a reconstrução forense da Verichains, a vulnerabilidade foi introduzida em 28 de outubro de 2023, no commit 9a9e380 do código da Zodiac.

Esse commit alterou a forma como o contrato lidava com um staticcall (uma chamada de apenas leitura para outro contrato, que não deveria modificar o estado). Na modificação, o valor success — o booleano que indica se a chamada teve sucesso ou reverteu — foi descartado, restando apenas a verificação do «valor mágico» nos dados de retorno. Traduzindo: o contrato parou de perguntar «esta chamada funcionou?» e passou a perguntar apenas «os dados que você me devolve têm o formato correto?». Como o atacante controlava esses dados de retorno mesmo em uma chamada que revertia, ele podia construir uma resposta com o formato correto a partir de uma operação que, na realidade, havia falhado.

Durante dois anos e meio, essa falha esteve latente. Não foi explorada porque não era trivial de encontrar e porque exigia uma combinação específica de condições: uma conta com o Delay Modifier v1.1.0 (ou o Roles Modifier v2) habilitado, junto a uma Safe que utilizasse um fallback handler (o contrato que gerencia chamadas não previstas explicitamente) vulnerável e atribuído como módulo ou como membro de função. Uma configuração específica, mas exatamente a que a infraestrutura da Gnosis Pay possuía.

O que foi o «patch fantasma» de fevereiro?

Em 27 de fevereiro de 2026 — três meses antes do exploit — a equipe da Zodiac corrigiu a falha. O commit de fusão 11708ac no repositório gnosisguild/zodiac-core — a pull request #34, «Simplify Base Contracts», parte da versão v4.0.0-alpha.0 — reescreveu os contratos base. Entre suas mudanças, o sub-commit f06f07b ajustou a validação EIP-1271 «para verificar o sucesso do staticcall»: ou seja, reinseriu a pergunta que o commit de 2023 havia eliminado: «esta chamada funcionou realmente?».

O patch estava correto. Era público. Estava no GitHub, mergeado no branch principal, acessível para qualquer um que quisesse ler. E não serviu de nada, porque o contrato que custodiava o dinheiro da Gnosis Pay nunca o recebeu.

A razão reside na gestão de dependências, não na criptografia. A linha de código nova e corrigida vivia no pacote zodiac-core. Mas as instâncias do Delay Module em produção continuavam compiladas contra o pacote antigo, @gnosis.pm/zodiac, uma dependência legacy que nunca recebeu o backport da correção. O ecossistema havia se fragmentado em duas linhagens de código: a nova, onde o bug estava morto, e a velha, ainda em uso, onde ele permanecia vivo. A pergunta forense levantada pela Verichains é exatamente esta: por que as instâncias da Gnosis Pay em produção continuavam compiladas contra uma dependência obsoleta quando existia uma linhagem mais nova que já havia resolvido essa classe de bug?

Por que um fix no repositório não é um fix em produção?

Este é o cerne da questão e a parte que a cobertura mais superficial ignorou ao publicar a manchete «Gnosis Pay foi hackeada». Um contrato inteligente não se atualiza sozinho quando alguém faz o merge de um pull request no GitHub. O bytecode que roda na blockchain é uma fotografia imutável do código tal como estava no momento da implantação. Mergear uma correção upstream não altera esse bytecode. Para que o fix chegue à rede, alguém precisa recompilar contra a versão corrigida e implantar novamente o contrato (ou, em arquiteturas atualizáveis, apontar o proxy para uma nova implementação). Até que isso ocorra, o repositório e a rede divergem.

A analogia é a de qualquer implantação de software moderno. Uma equipe corrige uma falha de segurança em uma biblioteca e publica uma versão nova. Seu serviço em produção não fica protegido por mágica: ele continua executando a imagem de container que você construiu meses atrás, com a versão antiga da biblioteca empacotada dentro, até que você refaça o build e o redesploy. A diferença é que na nuvem o redesploy é um comando rotineiro; on-chain é uma operação dispendiosa, às vezes irreversível, e que pode exigir governança, migração de usuários ou pausa no sistema. O incentivo para não mexer no que «está funcionando» é muito mais forte. E é por isso que o gap entre repositório e produção tende a aumentar com o tempo, não a diminuir.

Há um agravante de transparência que quase ninguém comenta. Um patch público em um repositório open-source é, para um atacante atento, um mapa. O commit que corrige um bug descreve o bug. Qualquer um que monitore os repositórios das bibliotecas de segurança mais usadas pode ler um fix, deduzir a vulnerabilidade que ele corrige e verificar quais contratos em produção continuam sem aplicá-lo. A transparência que torna o open-source confiável é, na janela entre o fix e a nova implantação, exatamente a pista que o adversário precisa.

Onde o modelo mental «open-source e auditado» falha?

O caso da Gnosis Pay desmorona várias crenças confortáveis sobre por que um sistema cripto «deveria» ser seguro. Vale a pena confrontá-las com a realidade operacional.

Nenhuma dessas crenças é absurda. Todas são razoáveis como ponto de partida. O problema é tratá-las como garantias em vez de condições necessárias, mas insuficientes. «Auditado» reduz o risco; não o elimina, e certamente não cobre a divergência posterior entre o auditado e o implantado.

Como a Gnosis, Zodiac e Safe responderam?

A resposta ao incidente foi, em termos de procedimento, rápida e razoavelmente transparente. A Gnosis pausou a bridge coordenando-se com os validadores para frear a saída de fundos. O cofundador Martin Köppelmann comprometeu-se a reembolsar integralmente os usuários afetados: «A Gnosis cobrirá todas as perdas dos usuários», publicou no X.

A equipe da Zodiac comunicou que esteve trabalhando diretamente com as contas afetadas antes da divulgação pública e que, no momento em que o aviso se tornou público, mais de 95% das contas afetadas identificáveis já haviam tomado medidas corretivas. A Safe Labs, por sua vez, apressou-se em esclarecer o perímetro da falha: os contratos inteligentes da Safe, a infraestrutura e a interface da Safe{Wallet} e a recuperação de contas não foram afetados. A vulnerabilidade estava isolada em módulos de terceiros da Zodiac — o Roles Modifier v2 e o Delay Modifier v1.1.0 — e só era ativada sob a combinação específica de condições descrita anteriormente.

Essa distinção é importante para não superdimensionar o risco sistêmico: não foi uma falha no núcleo da Safe, que sustenta uma fração enorme dos ativos em contratos inteligentes do ecossistema. Mas também não convém subdimensioná-lo: os módulos da Zodiac são usados por muitos protocolos para governança e gestão de tesouraria, e a lição sobre a linhagem de dependências se aplica a todos eles.

Como verificar se o contrato implantado possui os últimos patches?

O valor acionável deste caso é que o gap repositório-versus-produção é auditável. Não é uma fatalidade invisível. Tanto um protocolo que integra módulos de terceiros quanto um usuário avançado que confia fundos a um contrato podem verificar boa parte do que falhou aqui. Este é o checklist mínimo.

• Identifique a versão exata implantada, não a do repositório. Leia no explorador de blocos o código verificado do contrato em produção e anote contra qual versão da biblioteca ele está compilado. O número que importa é o do bytecode on-chain, não o do README do GitHub.
• Verifique a linhagem do pacote. Distinga se o contrato depende do pacote ativo ou de um legacy. Neste caso, a diferença entre zodiac-core e @gnosis.pm/zodiac foi a diferença entre estar protegido e não estar. Um pacote descontinuado pode não receber backports de segurança.
• Acompanhe os commits de segurança das bibliotecas que você usa, não apenas seus releases. Um fix pode chegar em uma versão alpha ou em um commit isolado meses antes de um release «oficial». Monitore o histórico, não apenas as tags de versão.
• Trate cada patch upstream como uma tarefa de nova implantação, não como um evento já resolvido. Mergear não é implantar. Mantenha um inventário de quais contratos em produção dependem de quais bibliotecas e com qual versão, para saber o que precisa ser reimplantado quando um fix aparece.
• Quando surgir um patch público em uma biblioteca que você utiliza, assuma que é informação pública também para o atacante. A janela entre o fix e sua nova implantação é uma corrida. Priorize-a como tal.
• Como usuário, minimize o saldo em hot wallets. Se um produto custodia fundos em um contrato com módulos complexos, mantenha on-chain apenas o que for usar a curto prazo e revise quais módulos você tem habilitados em sua Safe.

Nenhum desses passos exige ser um auditor. Exigem tratar a implantação como parte da superfície de segurança, e não apenas o código.

Qual padrão este caso deixa para o restante do DeFi?

O exploit da Gnosis Pay é a face oposta dos ataques à cadeia de suprimentos de software que marcaram 2026. Naqueles, código malicioso se infiltra em uma dependência e se propaga para a produção sem que ninguém perceba. Aqui ocorreu o inverso e, de certa forma, mais incômodo: o código legítimo e corretivo existia, mas não se propagou. A falha não foi dos desenvolvedores que encontraram e corrigiram o bug. Foi da cadeia que deveria levar essa correção do repositório até o bytecode que custodiava o dinheiro.

A lição estrutural é que a segurança de um sistema cripto não é decidida apenas no código nem apenas na auditoria. É decidida também, e talvez principalmente, na disciplina de implantação: em saber qual versão roda na rede, contra quais dependências está compilada e com qual atraso em relação aos patches conhecidos. Em um ecossistema que se orgulha da transparência, o dado mais opaco costuma ser precisamente este: a distância entre o que diz o repositório e o que executa o contrato. Quem a medir terá uma vantagem de segurança real sobre quem se conformar com o selo de «open-source e auditado».

Fontes e links: Verichains — post-mortem técnico · GitHub gnosisguild/zodiac-core · The Defiant · CryptoTimes