XRP Ledger corrige falha que poderia criar 18 trilhões
Uma falha no mecanismo de pagamentos do XRP Ledger poderia, em teoria, criar cerca de 18 trilhões de XRP utilizáveis em uma única transação. A XRP Ledger Foundation e a RippleX divulgaram o problema após corrigirem a vulnerabilidade no xrpld 3.4.1. No entanto, a apuração não encontrou evidências de exploração na rede pública nem de criação não autorizada de unidades. Portanto, o caso expôs um risco à integridade da oferta, mas não confirmou uma violação.
Como a vulnerabilidade afetava os pagamentos
O mecanismo de pagamentos pode consumir ofertas do livro de ordens enquanto uma operação percorre uma rota de negociação. Nesse processo, a vulnerabilidade permitia um estouro de inteiro durante a soma dos valores de várias ofertas. Quando a soma ultrapassava o limite da representação numérica, o resultado retornava a um valor pequeno em vez de gerar um erro. Assim, o sistema poderia registrar um total inferior ao valor efetivamente pago aos proprietários das ofertas.
Cada proprietário receberia integralmente sua parcela, mas o comprador pagaria apenas o total reduzido após o estouro. Com isso, a diferença corresponderia à criação de novos XRP. Além disso, a verificação criada para impedir essa emissão utilizava a mesma aritmética vulnerável. Dessa forma, o mecanismo de segurança não identificava a discrepância.
Correção chegou com o xrpld 3.4.1
A falha afetava o xrpld 3.4.0 e as versões anteriores. O programa de recompensa por bugs do XRPL recebeu o relato em 22 de setembro de 2026. Segundo o relatório de vulnerabilidade, o erro pode existir desde 2015, quando os desenvolvedores criaram o atual mecanismo de pagamentos. Por sua vez, a divulgação de 9 de outubro informa que o xrpld 3.4.1 chegou em 25 de setembro.
Na versão atualizada, o mecanismo verifica possíveis estouros durante a soma dos valores das ofertas. Caso o total ultrapasse o limite, o caminho de pagamento falha. Ao mesmo tempo, a checagem destinada a impedir a criação de XRP passou a utilizar um contador maior. O projeto também reforçou outros trechos de código responsáveis por somar saldos.
Exposição teórica não representa emissão confirmada
A estimativa de 18 trilhões de XRP descreve o que a vulnerabilidade poderia permitir em uma única transação. Esse volume equivale a aproximadamente 180 vezes a oferta planejada de 100 bilhões de XRP. Entretanto, os investigadores não encontraram sinais de exploração pública ou emissão não autorizada. Logo, o impacto potencial não representa um evento observado no mercado ou na oferta do XRP.
Para acionar o erro, um invasor precisaria criar ofertas específicas e estruturar um pagamento capaz de consumi-las em conjunto. Portanto, pagamentos e negociações comuns não provocariam a falha acidentalmente. O relatório também não aponta comprometimento confirmado da rede pública ou perdas de fundos. Ainda assim, a condição técnica representava um risco relevante para a segurança do ledger.
Outro problema envolveu transações Batch
O xrpld 3.4.1 corrigiu dois bugs. O segundo afetava a validação de wrappers internos em transações Batch e atingia as versões 3.3.0 e 3.4.0. Contudo, a emenda BatchV1_1 não estava ativa na Mainnet quando os responsáveis identificaram a questão. Por isso, esse problema não tinha relação direta com o estouro no mecanismo de pagamentos.
“É oficial. O XRP Ledger corrigiu uma falha de estouro, com cerca de uma década, no mecanismo de pagamentos. Ela poderia permitir que um invasor criasse aproximadamente 18 trilhões de XRP utilizáveis em uma única transação.”
MSB Intel, no X.
A atualização 3.4.1 tornou-se a versão mínima exigida após a ativação de emendas recentes. Porém, a principal lição de segurança vai além do cálculo de pagamentos. Uma verificação independente pode falhar quando repete a mesma aritmética insegura da lógica que deveria fiscalizar. Nesse sentido, a correção buscou proteger a integridade da oferta de XRP em diferentes camadas do código.
| | Receba nossas últimas notícias em primeira mão. Adicione-nos como sua fonte preferida no Google e toque em “Favorito” para priorizar nossas atualizações. |
|---|