Falha no XRP Ledger Descoberta por IA Expôs Caminho para Cunhar 18,45 Trilhões de XRP

A Veria AI encontrou uma falha no XRP Ledger que, segundo pesquisadores, poderia cunhar 18,45 trilhões de XRP, apesar da oferta fixa de 100 bilhões da criptomoeda.

O exploit combinava aritmética defeituosa no mecanismo de pagamentos do ledger com uma verificação de segurança que repetia o mesmo erro. Um pagamento especialmente construído poderia creditar centenas de contas vendedoras enquanto cobrava quase nada do comprador.

A RippleX reproduziu o exploit, classificou-o como crítico e lançou o xrpld 3.4.1 em 25 de setembro de 2026. A divulgação oficial afirma que os investigadores não encontraram evidências de que alguém tenha explorado a vulnerabilidade em uma rede pública.

Essa distinção é importante. Não se tratou de um roubo de 18 trilhões de XRP, nem o valor teórico tinha valor de mercado realizável. Era um caminho crível para violar a regra fundamental de oferta do XRP.

O incidente também testa uma promessa mais ampla em torno da segurança assistida por IA. Um agente de IA aparentemente encontrou um defeito de uma década que auditorias e testes convencionais não haviam detectado. Ainda assim, pesquisadores humanos precisaram validar o resultado, coordenar uma correção confidencial e convencer os validadores a atualizarem seus sistemas.

A Falha no XRP Ledger Foi Corrigida Antes da Divulgação Pública

A história imediata é uma resposta emergencial bem-sucedida a uma vulnerabilidade que permaneceu acessível por quase uma década.

A Veria Labs afirma ter direcionado seu agente de segurança ao rippled, o software de servidor de código aberto usado pelo XRP Ledger. A empresa diz que seu sistema identificou o código vulnerável, desenvolveu um exploit funcional e o testou em uma rede local.

A reconstrução técnica da empresa data a descoberta inicial pela IA em 21 de setembro. Segundo a Veria, o sistema produziu uma prova de conceito funcional no dia seguinte.

O pesquisador Cayden Liao revisou o resultado e o reportou por meio do programa de recompensa por bugs da XRPL em 22 de setembro. Engenheiros da RippleX confirmaram o problema naquele mesmo dia após reproduzi-lo em um servidor independente e em sua estrutura de testes.

A confirmação foi além de demonstrar uma discrepância contábil. A RippleX estabeleceu que o XRP recém-criado poderia ser transferido em um pagamento posterior, tornando o resultado operacionalmente utilizável.

Os desenvolvedores integraram uma correção em 23 de setembro e lançaram o rippled 3.4.1 dois dias depois. A divulgação pública aguardou até 9 de outubro, após os operadores receberem tempo para instalar o software corrigido.

A Veria afirma que mais de 80% dos validadores executavam a versão em 25 de setembro. A conta oficial da XRPL relata de forma semelhante que mais de 80% dos validadores na Unique Node List padrão atualizaram naquele dia.

Uma Unique Node List, ou UNL, identifica os validadores nos quais um servidor confia ao avaliar o consenso. A rápida adoção entre esses validadores reduziu o risco criado por nós mais antigos que continuavam aceitando a transação vulnerável.

A resposta se afastou do caminho normal para alterar o comportamento das transações. A XRPL geralmente introduz mudanças sensíveis ao consenso por meio de emendas, que os validadores avaliam antes da ativação.

Em vez disso, os desenvolvedores incluíram a correção do overflow diretamente na versão do servidor. Eles retiveram temporariamente as alterações relevantes no código-fonte, limitando a possibilidade de atacantes fazerem engenharia reversa da vulnerabilidade antes que validadores suficientes tivessem atualizado.

Essa escolha concentrou a confiança nos mantenedores e operadores de validadores por um curto período. Também evitou que um processo público de emenda se transformasse em um manual para um bug de inflação imediatamente explorável.

O relatório oficial afirma que a XRPL Foundation, a RippleX e os validadores participantes consideraram a atualização confidencial mais segura do que deixar um exploit aberto disponível por semanas. A correção se tornou pública após a rede ultrapassar o limiar de segurança necessário.

A Veria recebeu a recompensa crítica máxima de US$ 250.000 em 8 de outubro. O valor reconhece a classificação de gravidade, mas não deve ser confundido com uma perda mensurada.

Nenhum XRP não autorizado foi encontrado, nenhuma perda de fundos de usuários foi relatada e nenhuma transação no ledger público foi vinculada ao exploit. A emergência dizia respeito ao que o código aceitava, não a danos já observados.

Esse resultado torna fácil minimizar o evento. No entanto, evitar a exploração não reduz a importância de um defeito que poderia invalidar a premissa de oferta fixa do ativo.

Como a Falha no XRP Ledger Poderia Criar XRP Utilizável

O exploit funcionou porque duas salvaguardas monetárias realizavam cálculos vulneráveis de maneira quase idêntica.

O primeiro defeito surgiu no tratamento, pelo mecanismo de pagamentos, de ofertas da exchange descentralizada integrada ao XRP Ledger. As ofertas permitem que contas troquem XRP ou ativos emitidos por meio dos livros de ordens do ledger.

Um atacante começaria criando muitas contas controladas e emitindo um token sem valor. Essas contas então colocariam centenas de ofertas artificiais exigindo quantidades extremamente grandes de XRP por esse token.

A prova de conceito da Veria usou 256 ofertas. Cada uma solicitava pouco mais de 2^56 drops, sendo que um drop representa um milionésimo de um XRP.

O atacante então enviaria um pagamento projetado para consumir toda a coleção de ofertas. O mecanismo de pagamentos precisava somar os valores em XRP associados a cada oferta antes de cobrar o comprador.

Esse total excedia a capacidade do inteiro sem sinal de 64 bits usado no cálculo. Um overflow de inteiro ocorre quando um valor ultrapassa seu máximo permitido e retorna a um número muito menor.

Nesse caso, o agregado ultrapassava 2^64 drops. Os proprietários individuais das ofertas poderiam receber seus valores integrais, enquanto o overflow fazia a cobrança combinada do comprador parecer ser de apenas 256 drops.

Isso era mais grave do que uma cotação de exchange incorreta. Os saldos creditados representavam XRP que nenhuma conta de origem havia fornecido.

O resultado foi de aproximadamente 18.446.744.073.709 XRP, antes de considerar o débito da origem e a taxa da transação. A Veria resume a saída utilizável como cerca de 18,45 trilhões de XRP distribuídos entre 256 contas.

Essa distribuição era essencial. A XRPL impõe um limite ao XRP mantido por qualquer conta individual, mas cada destinatário permanecia abaixo desse teto.

Assim, o ataque contornava uma salvaguarda ao dividir o novo XRP entre muitas contas. Pesquisadores afirmam que o XRP creditado poderia então circular por pagamentos comuns ou chegar a exchanges.

A XRPL também tinha um invariante destinado a impedir exatamente esse resultado. Um invariante é uma condição de segurança pós-transação que deve continuar verdadeira antes de o ledger aceitar uma alteração.

O invariante XRPNotCreated calculava a variação líquida do saldo de XRP ao longo da transação. Ele deveria rejeitar qualquer resultado que mostrasse que a transação criou mais XRP do que destruiu por meio de taxas.

No entanto, esse cálculo usava aritmética vulnerável ao mesmo overflow. A variação líquida retornava até se parecer com uma queima de taxa comum, permitindo que a transação fosse aprovada.

Na prática, o mecanismo de pagamentos calculou incorretamente o que o comprador devia. A verificação de oferta aparentemente independente então repetiu a falha matemática e aprovou o resultado falso.

Essa falha compartilhada é a principal lição de projeto. Um controle de backup oferece proteção limitada quando depende do mesmo tipo de dado, comportamento aritmético ou premissa do componente que monitora.

O ataque não era algo que um trader comum pudesse acionar acidentalmente. Exigia centenas de ofertas com preços deliberadamente definidos e um pagamento projetado para consumi-las em conjunto.

Também exigia algum XRP para reservas de conta e de oferta, além de taxas de transação. O relatório de vulnerabilidade estima a exigência em algumas centenas de XRP, com a maior parte das reservas recuperável posteriormente.

O atacante não precisava controlar um validador. Depois de preparado e assinado, o pagamento exploratório entraria na rede como um pagamento aparentemente comum.

O ataque também era repetível. Grupos adicionais de contas controladas poderiam recriar a configuração, permitindo outro lote de 18,45 trilhões de XRP.

A correção introduziu verificações de overflow no código de soma das ofertas. Um total que excede o intervalo permitido agora falha em vez de retornar para uma cobrança pequena.

Os desenvolvedores também ampliaram o acumulador usado pelo invariante de oferta. Caminhos adicionais de soma de saldos receberam reforços relacionados para reduzir a chance de outra falha aritmética compartilhada.

Uma Oferta Fixa Tornou o Dano Potencial Sistêmico

A exposição real não era o valor nominal impossível de 18,45 trilhões de XRP, mas a credibilidade de cada unidade legítima já em circulação.

O XRP começou com uma oferta total de 100 bilhões de tokens. Ele não é produzido por mineração ou staking, e as taxas comuns de transação destroem pequenas quantidades ao longo do tempo.

Esse projeto oferece aos usuários uma expectativa monetária simples. As transações podem redistribuir XRP, mas nunca devem aumentar a oferta total.

A falha no XRP Ledger violava essa regra na camada contábil. Se explorada, poderia colocar XRP recém-criado em contas normais sem marcar visivelmente esses saldos como diferentes.

A saída reportada de 18,45 trilhões correspondia a cerca de 184 vezes a oferta original. No entanto, multiplicar essa quantidade pelo preço de mercado produz uma medida enganosa do dano econômico.

Um atacante não conseguiria vender trilhões de XRP ao preço anterior ao ataque. A liquidez disponível desapareceria, as exchanges poderiam suspender as negociações e o preço reagiria muito antes de a maior parte dos tokens encontrar um comprador.

A referência mais significativa era a capitalização de mercado de aproximadamente US$ 94 bilhões do XRP quando a Veria avaliou a vulnerabilidade. Isso representava o valor cuja premissa subjacente de escassez sofria pressão.

Mesmo esse número não é uma estimativa de perda garantida. A capitalização de mercado não equivale a dinheiro armazenado dentro de uma rede, e diferentes detentores enfrentariam resultados distintos.

O risco sistêmico vinha da confiança. A emissão não autorizada poderia diluir os detentores existentes, sobrecarregar a liquidez das exchanges, interromper aplicações e levantar dúvidas sobre as garantias contábeis do ledger.

As instituições também enfrentariam incerteza operacional. As exchanges talvez precisassem identificar depósitos afetados, provedores de pagamento poderiam pausar liquidações e custodians poderiam restringir saques durante uma investigação.

Essas respostas poderiam prejudicar usuários legítimos mesmo que um atacante capturasse apenas uma pequena parcela do valor divulgado. Uma falha de oferta se espalha além das contas diretamente envolvidas.

Isso ajuda a explicar a versão confidencial. Os mantenedores protegiam tanto o protocolo quanto a janela de resposta disponível para exchanges, validadores e provedores de infraestrutura.

A falha provavelmente existia desde que o mecanismo de pagamentos foi escrito em 2015. Uma segunda fraqueza no invariante de oferta datava de 2017, segundo a análise da Veria.

Essa linha do tempo coloca pressão sobre a ideia de que a longevidade, por si só, prova segurança. Um software pode processar bilhões de transações enquanto mantém um caminho de exploração que a atividade normal jamais aciona.

A Ripple afirmou em março que a XRPL havia processado mais de 100 milhões de ledgers e três bilhões de transações desde 2012. Esses números demonstram uso extensivo, mas não abrangem todos os estados aritméticos possíveis.

A entrada rara foi importante neste caso. Pagamentos normais não poderiam se aproximar do valor necessário para o overflow porque a oferta legítima de XRP estava muito abaixo desse limite.

Um invasor teria de fabricar valores extremos no livro de ordens em muitas ofertas. Testes convencionais baseados em comportamento econômico plausível talvez nunca tenham explorado essa combinação.

As auditorias também não eliminaram o risco. A Veria afirma que a base de código passou por mais de uma dúzia de auditorias ou concursos de auditoria desde 2024, além de um programa de recompensas já estabelecido.

Isso não prova que as auditorias tenham sido negligentes. Auditorias operam sob restrições de tempo, escopo e incentivos, enquanto interações raras podem permanecer ocultas entre componentes separados.

A lição é mais específica e mais útil. Código financeiro maduro precisa de testes que desafiem os limites da máquina, não apenas cenários que se assemelhem ao comportamento comum dos usuários.

A segurança com IA encontrou o bug, mas humanos o contiveram

A descoberta reforça a segurança assistida por IA, enquanto a resposta mostra por que a varredura autônoma é apenas uma camada da defesa de protocolos.

A Veria atribui tanto a descoberta quanto a construção do exploit ao seu agente de segurança com IA. A empresa afirma que o sistema analisou rippled, conectou as duas fraquezas aritméticas e criou uma prova de conceito local funcional.

Esse relato é relevante porque a vulnerabilidade exigia raciocínio entre componentes. Encontrar apenas o overflow de pagamento não garantiria sucesso caso a invariante de oferta rejeitasse a transação.

Segundo relatos, o agente reconheceu que a invariante repetia o overflow. Em seguida, projetou uma entrada que acionava as duas falhas dentro de uma única transação.

As alegações da Veria têm apoio externo significativo. A RippleX reproduziu o exploit de forma independente, confirmou a possibilidade de gastar o XRP emitido e elevou o relatório de grave para crítico.

A divulgação oficial do XRPL não apresenta uma avaliação completa da autonomia do agente. Ela confirma o relatório e o resultado técnico, mas não mede de forma independente quanto direcionamento humano levou à descoberta.

Essa lacuna importa ao avaliar produtos de segurança com IA. Uma descoberta bem-sucedida pode envolver análise automatizada de código, prompts elaborados por humanos, revisão iterativa e validação manual do exploit em proporções diferentes.

Ainda assim, o incidente fornece mais evidências do que uma pontuação de benchmark. Ele levou a uma vulnerabilidade crítica confirmada, a uma versão de produção e ao pagamento da recompensa máxima.

A Ripple já havia anunciado um programa mais amplo de segurança com IA em março de 2026. Esse programa combinava testes assistidos por IA com uma equipe dedicada de red team, fuzzing, verificação formal e análise mais rigorosa de amendments.

Testes de fuzzing fornecem ao software entradas inesperadas ou malformadas para expor falhas e estados inválidos. A verificação formal utiliza técnicas matemáticas para testar se o software atende a propriedades definidas.

Esses métodos lidam com modos de falha distintos. A IA pode inspecionar código e propor caminhos de ataque, fuzzers podem explorar espaços de entrada, e métodos formais podem testar invariantes críticos.

Engenheiros humanos ainda decidem se uma descoberta é alcançável, se seu impacto é real e como corrigi-la sem interromper o consenso. Eles também gerenciam a divulgação entre uma base descentralizada de operadores.

A resposta do XRP Ledger ilustra claramente essa divisão. O agente encontrou o caminho, Liao o revisou, e a RippleX reproduziu o exploit em ambientes controlados.

Os desenvolvedores então alteraram vários caminhos aritméticos. Operadores de validadores instalaram a versão, enquanto mantenedores monitoravam a adoção antes de divulgar os detalhes.

Nenhum participante controlou todo o desfecho. O sistema dependeu da cooperação entre uma empresa privada de segurança, desenvolvedores de código aberto, uma fundação, a RippleX e operadores independentes.

Essa coordenação é uma força porque várias partes examinaram a descoberta. Ela também é uma dependência de governança que merece escrutínio.

O patch de emergência foi distribuído antes de a explicação em nível de código-fonte se tornar pública. Os validadores tiveram de decidir se confiariam na versão sem receber a transparência normalmente disponível para mudanças de rotina.

A alternativa tinha seu próprio perigo. Publicar a mecânica exata do overflow antes de uma ampla adoção daria aos invasores um caminho funcional contra todos os validadores sem correção.

Essa é a principal troca envolvida, não uma simples disputa entre IA e auditoria humana. Uma descoberta mais rápida aumenta o valor de procedimentos de resposta rápidos, confiáveis e cuidadosamente governados.

As mesmas ferramentas que ajudam defensores a inspecionar código antigo também podem ajudar invasores a procurar erros equivalentes. A engenheira da RippleX Mayukha Vadari alertou na divulgação que a IA altera o tempo em torno da descoberta e da exploração de vulnerabilidades.

Por isso, um programa maduro precisa de mais do que scanners melhores. Precisa de divulgação confidencial ensaiada, padrões claros de severidade, canais de comunicação com validadores e prontidão de atualização mensurável.

O que a falha do XRP Ledger não prova

O exploit confirmado foi grave, mas várias interpretações de manchete vão além das evidências disponíveis.

Primeiro, não há evidências de que 18,45 trilhões de XRP tenham entrado em um ledger público. Pesquisadores criaram a saída em um ambiente controlado enquanto validavam a vulnerabilidade.

Segundo, nenhuma fonte estabeleceu que invasores conheciam o caminho antes de a Veria reportá-lo. A idade do código vulnerável descreve o tempo de exposição, não conhecimento adversarial confirmado.

Terceiro, os alegados US$ 94 bilhões em risco não devem ser tratados como uma previsão de perdas. O valor descreve o mercado cuja garantia de escassez enfrentava dano potencial.

Quarto, o incidente não estabelece que um sistema de IA tenha concluído de forma independente cada etapa da pesquisa. A Veria forneceu o relato mais detalhado sobre o papel do agente, enquanto humanos realizaram a revisão e a divulgação.

Essas ressalvas não tornam a descoberta teórica em sentido depreciativo. A RippleX reproduziu a transação e confirmou que um pagamento posterior poderia gastar o novo XRP.

A vulnerabilidade também chegou ao código de produção. Não se tratava de um recurso proposto detectado antes da ativação, ao contrário de um problema separado de transação Batch corrigido na mesma versão 3.4.1.

Combinar esses incidentes pode gerar confusão. A falha Batch dizia respeito à validação de wrappers e a uma possível divergência entre versões de servidores.

Esse amendment Batch não havia sido ativado na rede principal. Os validadores conduziram sua correção por meio de votação de amendments, e a versão corrigida foi ativada em 9 de outubro.

O overflow de XRP seguiu um caminho diferente. Ele afetava o comportamento existente do mecanismo de pagamentos e foi corrigido imediatamente quando os nós instalaram a versão 3.4.1.

O registro da versão contém, portanto, duas correções de segurança com históricos distintos de exposição e governança. Apenas o overflow de pagamento criou o alegado caminho de emissão.

Outra incerteza diz respeito à detecção histórica. O XRPL afirma não ter encontrado evidências de exploração em redes públicas, mas os leitores devem distinguir “nenhuma evidência” de uma prova absoluta de ausência.

Um invasor que usasse o exploit criaria mudanças incomuns de saldo e atividade no livro de ordens. Esses vestígios deveriam ajudar a análise retrospectiva, especialmente diante da necessidade de centenas de ofertas artificiais.

No entanto, a divulgação pública não apresenta uma metodologia forense completa nem uma busca no histórico do ledger auditada de forma independente. Sua conclusão continua sendo a descoberta relatada pelos mantenedores.

A rápida atualização da rede também merece exame contínuo. A adoção superior a 80% entre validadores da UNL padrão reduziu a exposição imediata, mas outros nós e provedores de infraestrutura seguem cronogramas diferentes.

Software antigo não pode se tornar seguro por meio de uma declaração de divulgação. Operadores que executam rippled 3.4.0 ou anterior continuam responsáveis por atualizar.

Por fim, esse evento não demonstra que a IA tenha tornado a auditoria de blockchain completa. Ele mostra que um processo assistido por IA encontrou um bug importante em uma base de código madura.

O próximo teste é a repetibilidade. Equipes de segurança precisam de evidências de que sistemas semelhantes encontram vulnerabilidades diversas e antes desconhecidas sem inundar mantenedores com relatórios fracos.

Elas também precisam avaliar o uso adversarial. Descoberta defensiva mais rápida só é valiosa quando correção e implantação conseguem superar a reprodução maliciosa.

Três sinais mostrarão se o modelo de segurança melhorou

A próxima fase deve ser julgada pelo código, pelo comportamento dos validadores e por resultados de segurança reproduzíveis de forma independente.

O primeiro sinal é a continuidade da adoção de rippled 3.4.1 ou posterior. A correção do overflow crítico é aplicada durante a instalação do software, portanto nós desatualizados continuam sendo o risco evitável mais evidente.

A telemetria pública dos validadores deve mostrar as versões vulneráveis desaparecendo de papéis relevantes no consenso. Uma adoção lenta enfraqueceria a alegação de que o XRPL consegue se coordenar sob condições urgentes.

O segundo sinal é uma revisão técnica das invariantes monetárias além deste patch específico. A verificação de oferta que falhou compartilhava comportamento aritmético com o componente que deveria monitorar.

Os desenvolvedores devem testar outros totais, conversões e caminhos de saldo com acumuladores mais amplos e tratamento explícito de overflow. Uma revisão independente fortaleceria a confiança mais do que outra garantia genérica.

O terceiro sinal é a evidência de que testes assistidos por IA produzem descobertas repetíveis sob divulgação responsável. Vulnerabilidades confirmadas, baixas taxas de falsos positivos e supervisão humana clara sustentariam a alegação mais ampla da Veria.

Uma sequência de relatórios sensacionalistas, mas não verificados, a enfraqueceria. O mesmo ocorreria com descobertas que exigem extensa reconstrução humana não divulgada antes de se tornarem acionáveis.

O incidente já muda a base de segurança. Operação prolongada, auditorias anteriores e um desenho de oferta em declínio não impediram que um erro de limite de máquina ameaçasse a regra monetária central do XRP.

Ao mesmo tempo, a resposta funcionou antes que surgisse um exploit público. Pesquisadores relataram o problema, engenheiros o reproduziram, e validadores instalaram uma correção de emergência em poucos dias.

Desenvolvedores e operadores de infraestrutura devem agora perguntar se suas próprias verificações de segurança falham de modo diferente dos sistemas que supervisionam. Uma suposição duplicada não é verdadeira defesa em profundidade.

Para leitores que acompanham a falha do XRP Ledger, a ação mais útil é observar a adoção de versões, a revisão independente do código e futuras divulgações de recompensas. Esses sinais revelarão se esta foi uma correção isolada ou o início de um modelo de segurança mais robusto.