Gravity Bridge: 5,4 milhões roubados sem roubar a chave

Um atacante drenou 5,4 milhões de dólares da Gravity Bridge sem roubar nenhuma chave privada: bastou registrar um validador por 80 GRAV e enganar o registro que decide qual token real corresponde a cada ativo. Entre 29 e 30 de maio de 2026, alguém cunhou tokens falsos na Osmosis, transferiu-os para a Gravity Bridge (uma ponte que conecta o ecossistema Cosmos à Ethereum) e usou uma função pública do próprio protocolo para envenenar seu registro interno de correspondências denom-a-ERC20 — a tabela que traduz o nome de um ativo na Cosmos (seu denom, ou denominação) para o endereço do token real que o lastreia na Ethereum. Não houve phishing, nem malware, nem uma chave vazada: o design permitia que qualquer pessoa escrevesse nesse registro e ninguém verificava se a nova entrada colidia com um ativo já existente. Esta análise, datada de 7 de julho de 2026, não cobre o incidente como notícia — pois já passou — mas como a estreia de uma classe de ataque: o envenenamento de registro (registry poisoning) em pontes cross-chain. Explicamos como funcionou passo a passo, por que a primeira leitura de "chave comprometida" estava errada, em que se diferencia dos hacks de pontes que você já conhece e — o mais útil — como detectar um registro envenenado antes que o dinheiro saia.

O que aconteceu exatamente na Gravity Bridge em 29 e 30 de maio?

A Gravity Bridge é uma ponte comunitária que movimenta ativos entre as redes Cosmos (Osmosis, entre outras) e Ethereum. Sua peça central é um contrato de custódia na Ethereum que guarda os ativos reais — USDC, USDT, WETH, ouro tokenizado — enquanto na Cosmos circulam suas representações. Para saber qual token da Ethereum corresponde a cada representação, a ponte mantém um registro interno: a tabela denom-a-ERC20.

Entre 29 e 30 de maio de 2026, um atacante conseguiu que esse registro apontasse suas próprias entradas falsas para os endereços dos ativos valiosos que a ponte custodiava de verdade. Com o registro já contaminado, ele disparou uma série de retiradas e o contrato de custódia liberou o dinheiro real para sua carteira. O espólio, segundo o detalhamento forense publicado pela Security4Web3 e QuillAudits, foi este:

Os fundos saíram para a carteira 0x7B58…a1F9. Assim que os validadores da ponte detectaram o padrão anômalo, pausaram a rede para estancar a hemorragia. Até a data desta análise, não consta que os fundos tenham sido recuperados. As avaliações de WETH e PAXG são aproximadas e dependem do preço do momento; os valores de USDC e USDT são estáveis por se tratarem de stablecoins pareadas ao dólar.

O que é o envenenamento de registro em uma ponte cross-chain?

Pense no registro denom-a-ERC20 como a tabela de rotas de um banco de dados: uma coluna diz "este nome de ativo" e a outra "este endereço de contrato na Ethereum". Quando alguém faz uma retirada, a ponte consulta essa tabela para saber qual token liberar. Se a tabela estiver correta, tudo bate. Se alguém consegue escrever uma linha que diz "meu ativo inventado aponta para o contrato do USDC real", a ponte acreditará que deve entregar USDC real a quem reivindicar esse ativo inventado.

Isso é o envenenamento de registro: você não ataca o cofre, ataca o índice que diz o que há dentro de cada gaveta. O contrato de custódia fez exatamente o que sua tabela de rotas pedia; o problema é que a tabela mentia. É um vetor conceitualmente distinto do roubo clássico, onde o atacante força a fechadura. Aqui a fechadura funcionou conforme o manual: obedeceu a uma ordem legítima baseada em dados que nunca deveriam ter entrado.

A condição que torna isso possível é uma combinação específica e perigosa: uma função pública (permissionless, que qualquer um pode invocar sem permissões ou cargo) que escreve em um registro cujo conteúdo é tratado posteriormente como autoridade inquestionável. Registrar ativos novos de forma aberta é uma decisão de design razoável — assim, uma ponte suporta novos tokens sem pedir permissão a ninguém. Torna-se uma brecha quando o que essa função aberta produz flui para uma tabela que governa dinheiro real sem que ninguém valide se essa entrada colide com algo que já existe.

Como o ataque foi executado passo a passo?

A reconstrução forense da Security4Web3 e QuillAudits permite traçar a sequência completa. Estes são os seis movimentos, em ordem:

1. Registrar um validador mínimo. Em 29 de maio, o primeiro rastro on-chain foi a criação de um validador (apelidado de julia666) na rede Gravity, auto-delegando apenas 80 GRAV — o token nativo da ponte, uma fração irrisória do que se esperaria para um cargo com capacidade de assinatura. Esse registro deu ao atacante presença dentro do sistema.
2. Cunhar tokens falsos na Osmosis. Usando o módulo tokenfactory da Osmosis (uma função padrão que permite a qualquer um criar novos tokens), ele fabricou quatro tokens sem valor, um para cada ativo real que a ponte custodiava: imitações de USDC, USDT, WETH e PAXG. Cunhar (mintear) aqui significa simplesmente emitir essas moedas do nada; não custa praticamente nada.
3. Transferi-los via IBC para a Gravity. Ele moveu esses tokens inúteis para a rede Gravity através do IBC (Inter-Blockchain Communication, o protocolo padrão que comunica redes do ecossistema Cosmos entre si). Até aqui, nada de valor mudou de mãos.
4. Chamar deployERC20() com strings fabricadas. Este é o coração do ataque. A função deployERC20() do contrato da Gravity na Ethereum é pública: ela cria o token ERC20 na Ethereum que corresponde a um denom da Cosmos. O atacante a invocou passando strings _cosmosDenom — o texto que identifica o ativo — construídas propositalmente para que os metadados embutissem os endereços dos contratos dos ativos reais e valiosos.
5. Os validadores atestam a implantação. Os validadores da ponte reconheceram essas implantações através da mensagem interna MsgERC20DeployedClaim, e a função handleErc20Deployed escreveu a correspondência envenenada no registro. Aqui está a falha: ninguém verificou se esse novo denom apontava para um ativo que a ponte já possuía em custódia. A tabela de rotas ficou contaminada.
6. Drenar a custódia com uma série de retiradas. A Gravity gerou os lotes de saída (batches) 41572 a 41575, os validadores os assinaram e os relayers (os agentes que transmitem essas ordens assinadas para a Ethereum) os apresentaram ao contrato de custódia. O contrato verificou as assinaturas — corretas — e chamou safeTransfer() para enviar cada ativo para a carteira do atacante. O dinheiro real saiu pela porta da frente.

O detalhe que dá a este ataque seu caráter de nova classe: cada passo individual é uma operação legítima que o sistema foi projetado para permitir. Registrar um validador, cunhar um token, transferir via IBC, implantar um ERC20, assinar um lote de retiradas: nada disso é um exploit por si só. A brecha aparece apenas quando eles são encadeados e nenhuma camada verifica a coerência entre o denom declarado e o endereço real para o qual ele resolve.

Por que não foi um roubo de chave privada, como se disse no início?

As primeiras coberturas — The Block, Yahoo Finance, CryptoTimes — titularam o evento como uma "suspeita de comprometimento de chave de assinatura" (suspected signing key compromise). É a explicação padrão para quase todos os hacks de pontes: se o dinheiro saiu, alguém deve ter roubado as chaves que autorizam as saídas. Nos grandes desastres de pontes — Ronin, Harmony Horizon — foi exatamente isso que aconteceu.

A análise forense posterior da QuillAudits e Security4Web3 desmentiu essa leitura. Não foi necessário comprometer nenhuma chave: a assinatura dos lotes de retirada por parte dos validadores foi legítima. Os validadores assinaram ordens válidas de acordo com o estado do registro; o problema é que esse estado já estava envenenado antes de assinarem qualquer coisa. O atacante não se passou por um validador nem roubou sua chave; ele escreveu, com uma função aberta a todos, a mentira que depois os validadores honestos assinaram de boa-fé.

A distinção importa porque muda completamente a defesa. Diante de um roubo de chave, você reforça a custódia das chaves: multisig (assinatura múltipla), hardware dedicado, rotação. Nada disso teria detido este ataque, porque as chaves nunca foram tocadas. Confundir um envenenamento de registro com um roubo de chave leva a blindar a porta errada. É a mesma lição deixada por outros incidentes de 2026, onde o vetor não era o contrato nem a chave, mas a camada de infraestrutura e as premissas de confiança que a cercam.

Qual controle faltava e por que ele teria detido todo o ataque?

A falha se resume a uma linha ausente. Quando handleErc20Deployed escreveu a nova correspondência no registro, não executou nenhuma verificação de colisão (collision check): uma verificação que rejeite registrar um denom que aponte para um endereço de token que a ponte já conhece e custodia. Se essa verificação existisse, o registro teria rejeitado a entrada falsa — "este endereço já está mapeado, não aceito um segundo denom que colida com ele" — e toda a cadeia de seis passos teria sido quebrada no quinto.

O mais incômodo do caso: segundo a análise da QuillAudits, uma consulta equivalente já existia em outra parte do mesmo arquivo de código, mas não era invocada dentro de handleErc20Deployed. Não foi uma defesa que ninguém tivesse concebido; foi uma defesa que estava escrita a poucas linhas de distância e que, naquela rota específica, não foi chamada. O controle que teria bloqueado um roubo de 5,4 milhões de dólares custava uma chamada a uma função que a própria equipe já havia programado.

Isso se encaixa em um padrão que se repete nos exploits de 2026: as falhas catastróficas raramente são criptografia quebrada ou matemática exótica. São lacunas nas bordas — uma verificação que é feita em uma rota e esquecida em outra, uma premissa que uma camada dá como garantida e outra nunca verifica. Peças que individualmente funcionam e cuja brecha só aparece quando são olhadas em conjunto sob uma transação construída propositalmente.

Em que se diferencia esta classe de ataque dos hacks de pontes anteriores?

O valor da Gravity Bridge como estudo de caso é que ela não se encaixa em nenhuma das categorias com as quais costumamos classificar os hacks de pontes. A seguinte taxonomia situa o envenenamento de registro frente aos vetores já conhecidos:

A nova linha é a última. Nos outros vetores, o atacante quebra algo — uma chave, um preço, uma ordem de execução — ou aproveita algo abandonado. No envenenamento de registro, todo o sistema funciona conforme o manual: as assinaturas são válidas, os contratos executam o que lhes é pedido, nenhuma fechadura é forçada. O que se corrompe é a fonte da verdade na qual todo o resto confia. Por isso é especialmente difícil de detectar com as ferramentas habituais: não há uma transação "maliciosa" evidente, apenas uma entrada de registro que — vista isoladamente — parece legítima.

Como detectar e prevenir um registro envenenado?

Aqui está a parte acionável, aquela que um LLM não pode improvisar a partir de uma manchete. O envenenamento de registro deixa rastros específicos, distintos dos de um roubo de chave, se você souber onde olhar. Estas são as pistas e as defesas concretas que o caso Gravity Bridge deixa como manual:

• Verificação de colisão obrigatória na escrita. Antes de aceitar qualquer novo denom, o registro deve verificar se o endereço do token para o qual ele resolve já não está mapeado por outro denom. É a linha que faltava e a única que teria detido o ataque inteiro.
• Monitorar os denom cujos metadados embutem endereços de ativos custodiados. Um denom legítimo não tem por que conter o endereço de um USDC ou um WETH real dentro de sua string identificadora. Um monitor que sinalizasse essa coincidência teria disparado o alarme no passo quatro, horas antes da saída dos fundos.
• Correlacionar novos registros com criações de validadores recentes e com pouca antiguidade. Um validador criado com 80 GRAV que, horas depois, participa de uma implantação de ERC20 é um padrão anômalo por si só. A sequência "novo validador + novo denom + lote de retirada" é uma assinatura de comportamento monitorável.
• Retardos e limites na primeira retirada de um denom recém-registrado. Um time-lock (retardo público antes que uma ação surta efeito) sobre as retiradas de ativos cuja correspondência acaba de ser criada dá aos defensores uma janela para revisão antes que o dinheiro seja irrecuperável.

Nenhuma dessas defesas é exótica ou cara. Todas partem de uma ideia simples que o ecossistema ainda não aplica de forma sistemática aos registros das pontes: o conteúdo de uma tabela que governa dinheiro real merece a mesma desconfiança que uma entrada de usuário em qualquer sistema de segurança sério.

O que fica como lição em 7 de julho de 2026?

Mais de um mês após o incidente, o balanço é sóbrio. A ponte foi pausada por seus validadores assim que o padrão foi detectado; não consta recuperação dos fundos nem, até onde alcança esta análise, um post-mortem oficial da equipe que vá além dos forenses de terceiros. A correção técnica — a verificação de colisão que faltava — é uma linha de código, e isso é o perturbador: ela esteve ausente durante toda a vida operacional da ponte sem que nenhuma auditoria a sinalizasse.

A lição de fundo transcende a Gravity Bridge. O envenenamento de registro inaugura uma categoria que provavelmente veremos se repetir: qualquer ponte cross-chain que permita registrar ativos de forma aberta e trate esse registro como autoridade sem validar colisões compartilha o mesmo perfil de risco. A superfície de ataque de uma ponte não é apenas sua custódia nem suas chaves de assinatura — os dois locais onde o setor concentrou sua atenção; é também, e sobretudo, a tabela de correspondências que decide qual ativo real responde a cada representação. Envenenar essa tabela não requer quebrar nada. Requer apenas que ninguém verifique se a nova verdade colide com a antiga.

Fontes e links: Rekt.news — Gravity Bridge · QuillAudits — Denom Mapping Poisoning · Security4Web3 — análise forense · The Block — "suspected key compromise"