Uma ponte cross-chain que já manteve mais de 200.000 XRP ficou com trocados em menos de duas horas, e ninguém precisou roubar uma única chave privada para que isso acontecesse. O hack da ponte XRP–Coreum drenou 99,7% da reserva que dava lastro ao conector Coreum-para-XRP Ledger em 9 de agosto, transformando o que deveria ter sido uma verificação de depósito de rotina em uma porta aberta para um invasor que simplesmente entendia o software melhor do que as pessoas que o operavam.
Summary
Pontos-chave
- Um invasor drenou 99,7% da reserva de XRP que dava lastro à ponte cross-blockchain da Coreum em 9 de agosto, deixando-a com cerca de 493 XRP.
- 199.916 XRP, no valor de mais de US$ 200.000, foram sacados em 94 transações em uma janela de cerca de 97 minutos.
- O exploit não envolveu chaves privadas roubadas; ele explorou um software de relayer com bugs que confiava em um memo de transação em vez de verificar o destino real do pagamento.
- TX, a marca por trás da Coreum e da Sologenic, confirmou o incidente, admitiu que o XRP em ponte em sua chain não está atualmente totalmente lastreado e afirmou que uma queixa foi registrada junto ao FBI.
- O XRP caiu abaixo de US$ 1 pela primeira vez desde novembro de 2024 à medida que a notícia se espalhou, embora a queda mais ampla da moeda neste ano seja anterior ao exploit.
O exploit que esvaziou a ponte da Coreum
A ponte da Coreum perdeu praticamente toda a sua reserva de XRP em uma única janela de ataque, fortemente comprimida. A conta de liquidez da ponte da Coreum desembolsou 199.916 XRP, avaliados em aproximadamente US$ 200.000, por meio de 94 transações separadas, e cada pagamento carregava a maioria das assinaturas válidas da própria rede de relayers da ponte. Em poucas horas, o projeto descobriu que detinha apenas 493 XRP, abaixo de um saldo que girava em torno de 200.410 XRP antes do início do ataque.
De acordo com a análise on-chain, os saques foram executados em cerca de 97 minutos, entre 19:16 e 20:53 UTC. Essa velocidade foi importante: deu ao invasor uma pista estreita, mas suficiente, para empurrar dezenas de solicitações de saque fraudulentas pelo processo de aprovação multisig da ponte antes que alguém percebesse que a reserva estava desaparecendo.
Isso não foi uma violação do próprio XRP Ledger. Nenhum validador foi comprometido e nenhuma carteira teve suas chaves roubadas. O dano veio inteiramente de uma falha na infraestrutura de ponte de terceiros que fica sobre o ledger, uma distinção que importa ao avaliar até onde as consequências podem se espalhar.
Como o software de relayer foi enganado
A mecânica por trás do exploit de XRP na Coreum revela uma lacuna surpreendentemente simples no design da ponte. O software de relayer foi construído para escanear o histórico de transações da conta da ponte em busca de pagamentos que carregassem um memo específico de destinatário na Coreum, tratando esse memo como prova de que um depósito havia realmente chegado. O que ele nunca fez foi confirmar se o pagamento havia de fato alcançado a carteira de destino correta.
O invasor aproveitou essa lacuna movendo tokens embrulhados sob seu controle entre carteiras que ele possuía, anexando um memo formatado para a Coreum a cada transferência. Como esses tokens embrulhados haviam sido originalmente emitidos pela própria ponte, as transações apareciam de forma limpa em seu histórico, sem nada que as sinalizasse como depósitos falsos. A lógica do relayer verificava o campo de memo e pouco mais, ignorando o endereço do destinatário que teria exposto o engano.
Esse ponto cego alimentou diretamente a forma como os saques foram aprovados. A autorização exigia que 17 das 28 chaves de relayer assinassem, e cada um desses operadores independentes estava executando o mesmo código com falhas. Como cada nó avaliou as mesmas evidências falsificadas e chegou à mesma conclusão errada, a salvaguarda descentralizada da ponte desabou em um único ponto de falha. Esta é a principal lição da vulnerabilidade no XRP em ponte: distribuir a confiança entre muitos operadores oferece pouca proteção se todos estiverem confiando na mesma lógica de verificação quebrada.
TX confirma a violação e aciona o FBI
A TX, a marca que unificou as comunidades Coreum e Sologenic em um único ecossistema em fevereiro, confirmou publicamente o incidente e não minimizou o que deu errado. A empresa admitiu que seu software “registrou incorretamente como depósitos transações que nunca entregaram qualquer XRP à ponte, e cunhou XRP em ponte na tx chain com base nelas”.
Essa admissão traz uma consequência financeira direta: a TX reconheceu que o XRP em ponte em circulação na tx chain “não está atualmente totalmente lastreado” após o exploit, o que significa que tokens destinados a representar uma reserva de XRP um-para-um agora estão apenas parcialmente colateralizados. A mesma declaração observou que a ponte passou por “múltiplas auditorias internas e de terceiros antes da implantação”, um detalhe que levanta questões desconfortáveis sobre como uma falha tão fundamental passou pela revisão. A TX também confirmou que uma queixa formal sobre o hack foi registrada junto ao FBI, e a ponte permaneceu suspensa nos dias seguintes à violação enquanto a equipe trabalhava em sua resposta.
Por que isso importa além da própria Coreum: o fato de um software de ponte auditado falhar em uma etapa de verificação tão básica sugere que o problema pode residir menos na complexidade do código e mais em quão minuciosamente sistemas cross-chain são testados sob estresse antes que dinheiro real flua por eles. Para qualquer projeto que ofereça ativos em ponte, esse é um alerta que vale a pena ler com atenção.
Reação do mercado enquanto o XRP cai abaixo de US$ 1
O timing do exploit foi incômodo para a tendência mais ampla de preço do XRP. O token caiu abaixo de US$ 1 nos dias seguintes ao hack, seu primeiro registro abaixo de um dólar desde novembro de 2024. O XRP já perdeu 45% de seu valor neste ano e está 74% abaixo de sua máxima histórica, uma queda que vinha se acumulando muito antes do incidente da ponte, mas que a notícia do exploit em nada ajudou a aliviar.
O episódio também surge como um estudo de caso de advertência para uma violação de segurança em ponte cripto de forma mais ampla. Pontes cross-chain dependem de relayers ou validadores atestando que algo realmente aconteceu em outra rede, e quando essa lógica de atestação tem um bug, todo o modelo de confiança construído sobre ela desmorona. Como essa falha estava na infraestrutura de ponte de terceiros, e não no protocolo central do XRP Ledger, o dano direto ao ecossistema XRP mais amplo pode acabar sendo contido. Mas a confiança em versões embrulhadas e em ponte de XRP, e em designs semelhantes baseados em relayers em outros lugares, é outra questão, que provavelmente dependerá de a TX conseguir mostrar que fechou a lacuna de forma definitiva.
Perguntas frequentes
Como o invasor conseguiu sacar XRP sem roubar chaves privadas?
O invasor explorou um software de relayer com bugs que validava depósitos apenas com base em memos de destinatário, sem verificar o destino real do pagamento, enganando o sistema para tratar depósitos fabricados como reais.
Por que operadores independentes aprovaram os saques fraudulentos?
Os operadores executavam o mesmo software vulnerável, que aceitava evidências falsas de depósito ao pé da letra. Como cada relayer confiava em uma lógica defeituosa idêntica, eles chegaram à mesma conclusão errada e assinaram saques que nunca foram legítimos.
Qual foi a resposta oficial da Coreum e da TX em relação ao exploit?
A TX confirmou o incidente, admitiu que o software registrou incorretamente como depósitos transações que nunca entregaram XRP de fato e revelou que o XRP em ponte na tx chain não está atualmente totalmente lastreado como resultado.
Que medidas legais foram tomadas após o hack?
Uma queixa sobre o hack foi registrada junto ao FBI, de acordo com o comunicado da TX que confirmou o incidente.
{“@context”:”https://schema.org”,”@type”:”FAQPage”,”mainEntity”:[{“@type”:”Question”,”name”:”Como o invasor conseguiu sacar XRP sem roubar chaves privadas?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”O invasor explorou um software de relayer com bugs que validava depósitos apenas com base em memos de destinatário, sem verificar o destino real do pagamento, enganando o sistema para tratar depósitos fabricados como reais.”}},{“@type”:”Question”,”name”:”Por que operadores independentes aprovaram os saques fraudulentos?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Os operadores executavam o mesmo software vulnerável, que aceitava evidências falsas de depósito ao pé da letra. Como cada relayer confiava em uma lógica defeituosa idêntica, eles chegaram à mesma conclusão errada e assinaram saques que nunca foram legítimos.”}},{“@type”:”Question”,”name”:”Qual foi a resposta oficial da Coreum e da TX em relação ao exploit?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”A TX confirmou o incidente, admitiu que o software registrou incorretamente como depósitos transações que nunca entregaram XRP de fato e revelou que o XRP em ponte na tx chain não está atualmente totalmente lastreado como resultado.”}},{“@type”:”Question”,”name”:”Que medidas legais foram tomadas após o hack?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Uma queixa sobre o hack foi registrada junto ao FBI, de acordo com o comunicado da TX que confirmou o incidente.”}}]}
Artigo produzido com a assistência de inteligência artificial e revisado pela equipe editorial.
