XRP Ledger revela falha crítica que poderia ter permitido a criação de novos XRP

O XRP Ledger (XRPL) divulgou em 9 de outubro de 2026 a existência de duas vulnerabilidades de software, incluindo um bug crítico que, em tese, poderia permitir a criação de novos XRP utilizáveis. A segunda falha envolvia o recurso de transações em lote (Batch) e poderia causar instabilidade na validação de transações. De acordo com o comunicado oficial, o problema no mecanismo de pagamentos foi corrigido no xrpld 3.4.1, lançado em 25 de setembro. O XRPL afirmou não ter encontrado evidências de exploração da vulnerabilidade em nenhuma rede pública. Falha no mecanismo de pagamentos poderia "criar" XRP A vulnerabilidade crítica estava ligada à forma como o mecanismo de pagamentos calculava o volume de XRP necessário para concluir operações que atravessam múltiplas ofertas em um livro de ordens. Quando o valor combinado excedia o limite máximo suportado pelo sistema, o cálculo podia sofrer overflow. Nesse cenário, o comprador poderia ser debitado em menos XRP do que o total creditado aos donos das ofertas, gerando na prática a emissão indevida de XRP. A exploração exigia um livro de ordens cuidadosamente montado, com centenas de ofertas e preços atipicamente altos, seguido de uma transação de pagamento específica. O XRPL ressaltou que o bug não poderia ser acionado por pagamentos ou negociações comuns. Um pesquisador reportou o caso pelo programa XRPL Bug Bounty em 22 de setembro de 2026. A equipe de engenharia da RippleX reproduziu o problema e confirmou que qualquer XRP gerado pela falha poderia ser gasto. A correção entrou no xrpld 3.4.1, com a adição de verificações para impedir overflow e reforço das proteções contra criação não autorizada de XRP. Segunda falha atingia transações em lote (Batch) A outra vulnerabilidade envolvia o recurso Batch, que permite enviar várias transações em conjunto. A falha possibilitava que uma transação dentro do lote utilizasse um campo estruturado de forma incorreta, ainda assim aceito e processado pelo servidor. O risco era que diferentes versões do software do XRPL divergirem sobre a validade da transação, o que poderia impedir os validadores de chegar a consenso e interromper a validação do ledger. Segundo o relatório, o problema não permitia burlar assinaturas nem viabilizava roubo direto de fundos. A correção foi implementada por meio do amendment fixBatchV1_2, que passa a exigir a estrutura correta das transações. Como o recurso Batch ainda não havia sido ativado na mainnet quando a falha foi identificada, o relatório não aponta contas ou recursos na mainnet afetados. Correção de segurança do Batch é ativada na mainnet Desenvolvedores do XRPL e operadores de validadores retiraram apoio ao amendment original do Batch para reiniciar o cronograma de ativação enquanto a equipe preparava a correção. O amendment ajustado ganhou suporte e foi ativado na mainnet em 9 de outubro de 2026, no mesmo dia em que o relatório da vulnerabilidade foi publicado. O documento também detalha uma mudança no processo de testes de segurança: o XRPL pretende retestar vulnerabilidades reportadas contra release candidates para confirmar a eficácia das correções antes de novos lançamentos. O que detentores de XRP precisam saber As duas vulnerabilidades foram corrigidas, e o XRPL afirma não ter evidências de exploração do bug crítico do mecanismo de pagamentos em rede pública. O relatório não conclui que qualquer uma das falhas tenha causado perda efetiva de fundos ou aumento real da oferta de XRP. A correção do mecanismo de pagamentos está no xrpld 3.4.1, enquanto o problema do Batch foi endereçado pelo amendment fixBatchV1_2. Não há orientação para detentores de XRP movimentarem recursos ou trocarem chaves privadas. A atualização é relevante sobretudo para operadores de servidores do XRPL, que precisam manter versões compatíveis para permanecer sincronizados com a rede.