A Ripple Labs lançou o xrpld 3.4.1 em 25 de setembro para corrigir duas vulnerabilidades no software de servidor do XRP Ledger. As falhas poderiam ter permitido a criação de XRP sem lastro adequado ou levado versões do servidor a discordar sobre transações em lote, potencialmente interrompendo a validação de novos ledgers.

A equipe do XRPL afirmou não ter encontrado evidências de que o estouro de inteiro tenha sido explorado em redes públicas, enquanto a falha de transações em lote não poderia afetar a mainnet antes da ativação da atualização de protocolo relevante.

A equipe do blockchain XRP Ledger publicou um relatório sobre as duas vulnerabilidades, ambas corrigidas no xrpld 3.4.1. A equipe também reforçou as verificações de saldo e planeja verificar novamente cada vulnerabilidade corrigida em novos candidatos a lançamento antes de encerrar os relatórios relacionados.

Estouro poderia ter criado XRP sem lastro

A primeira vulnerabilidade foi descoberta em 22 de setembro de 2026 por meio do programa de recompensas por bugs do XRPL. Um estouro de inteiro no mecanismo de pagamentos poderia ter permitido que um invasor criasse XRP sem lastro adequado usando ofertas especialmente elaboradas no livro de ordens e um único pagamento.

Ao processar centenas de ofertas, o software poderia somar incorretamente os montantes de XRP. Em vez de retornar um erro, um total excessivamente grande poderia transbordar e se transformar em um número pequeno. Os proprietários das ofertas ainda receberiam os montantes integrais, enquanto o comprador pagaria um montante muito menor.

Uma verificação padrão destinada a impedir que uma transação criasse novos XRP também poderia falhar devido a um estouro semelhante. A equipe do XRPL estimou que a vulnerabilidade poderia existir desde 2015, quando o atual mecanismo de pagamentos foi introduzido.

A versão 3.4.1 adicionou verificações de estouro ao calcular totais e rejeita operações inválidas. A equipe afirmou que não havia evidências de que a vulnerabilidade tivesse sido explorada em redes públicas.

Falha em transações em lote ameaçava a consistência da rede

A segunda vulnerabilidade surgiu durante uma revisão adicional dos resultados do Sherlock Attackathon. Denis Angell, da XRPL Foundation, confirmou em 18 de setembro que uma correção anterior estava incompleta. Mayukha Vadari, da RippleX, posteriormente determinou que a falha poderia fazer com que diferentes versões do software de servidor chegassem a conclusões conflitantes.

O problema envolvia o mecanismo Batch, que pode agrupar até oito transações em um único lote. O servidor não verificava se cada transação interna estava incluída no campo RawTransaction exigido. Diferentes versões do xrpld poderiam, portanto, interpretar de forma diferente a validade da mesma operação, potencialmente interrompendo a validação de novos ledgers sob determinadas condições.

A equipe corrigiu a falha por meio da atualização fixBatchV1_2, que foi ativada na mainnet em 9 de outubro. Antes dessa ativação, o problema não poderia ser explorado para afetar a mainnet porque a função BatchV1_1 correspondente permanecia inativa.

Outros trabalhos de segurança do XRPL

A Ripple Labs também trabalhou durante 2026 para reforçar a segurança e expandir as capacidades do XRPL. Em março, pesquisadores da RippleX apresentaram uma abordagem para transferências confidenciais de tokens multifuncionais, projetada para proteger dados dos usuários.

Em abril, a empresa anunciou um plano em várias fases para preparar o XRPL para ameaças da computação quântica, incluindo uma transição para criptografia pós-quântica até 2028. Em outubro, a CSD BR do Brasil iniciou a primeira etapa de uma parceria com a Ripple Labs para tokenizar cotas de fundos de investimento do BTG Pactual no XRPL.

Fonte: HODL Press