Segurança do XRPL reforçada após falha na emenda em lote do xrpl bloqueada antes da mainnet

A Fundação XRPL interrompeu uma questão grave relacionada com a emenda em lote do xrpl antes que pudesse afetar a mainnet, reforçando a postura de segurança em evolução do livro-razão.

Falha crítica detectada durante a fase de votação

A Fundação XRPL divulgou que uma vulnerabilidade crítica na proposta de emenda em lote foi identificada e neutralizada antes da ativação na mainnet. A falha surgiu enquanto a alteração ainda estava na fase de votação dos validadores, permitindo que os desenvolvedores respondessem antes de qualquer impacto na produção.

A questão foi descoberta em 19 de fevereiro de 2026 pelo engenheiro de segurança Pranamya Keshkamat, juntamente com a ferramenta autónoma Apex da Cantina AI. Segundo a fundação, nenhum fundo de utilizador esteve em risco, pois a emenda ainda não tinha sido ativada na mainnet do XRPL.

A emenda, formalmente conhecida como XLS-56, tinha como objetivo introduzir transações em lote no XRP Ledger. Permitia agrupar várias transações internas numa única operação, melhorando a eficiência e a coordenação. No entanto, essas transações internas eram intencionalmente deixadas sem assinatura, com a autorização delegada a uma transação de lote exterior que listava os signatários.

Como funcionava o erro na validação de assinatura

De acordo com o relatório pós-mortem da fundação, a vulnerabilidade estava enraizada na lógica de validação de assinatura do recurso em lote. Além disso, o problema centrou-se num erro de loop na função de validação do signatário usada para verificar as autorizações do lote.

Quando o sistema encontrava uma entrada de signatário ligada a uma conta que ainda não existia no livro-razão, podia sair do loop prematuramente. Se a chave de assinatura correspondesse à nova conta, o processo de validação era incorretamente marcado como bem-sucedido. Assim, o software pulava as verificações de todas as restantes entradas de signatários no lote.

Este comportamento abria uma via para transações não autorizadas. Um atacante poderia executar operações a partir de contas vítimas sem possuir as suas chaves privadas, pois as verificações de chaves dessas contas podiam ser contornadas. Na altura da descoberta, a emenda estava apenas na fase de votação dos validadores e permanecia desativada na mainnet.

A Fundação XRPL reforçou que a proposta não tinha sido ativada e reiterou: “A emenda estava na sua fase de votação e não tinha sido ativada na mainnet; nenhum fundo esteve em risco.” Esta garantia foi fundamental para limitar preocupações no mercado e destacar o benefício de testes rigorosos antes da ativação.

Impacto potencial do erro na emenda em lote

O cenário de exploração relatado requeria uma transação em lote cuidadosamente elaborada. Um atacante construía um lote contendo três operações internas, orquestradas para explorar a lógica defeituosa na validação do signatário.

Primeiro, uma transação interna criava uma nova conta totalmente controlada pelo atacante. Segundo, outra transação interna enviava uma transferência simples ou ação dessa conta recém-criada. Terceiro, uma transferência de uma conta vítima escolhida para a conta do atacante seria incluída, tentando mover fundos sem autorização legítima.

Para completar a configuração, o atacante forneceria duas entradas de signatário em lote. Uma entrada de signatário seria válida para a nova conta controlada pelo atacante. A segunda entrada de signatário alegaria falsamente autorizar transações para a conta vítima. No entanto, devido ao erro de saída precoce do loop, o sistema poderia aceitar o primeiro signatário e nunca validar corretamente o segundo.

Como resultado, o pagamento da vítima poderia ser executado sem assinatura válida, alterando o livro-razão de formas que a vítima não aprovou. A Fundação XRPL alertou que o uso bem-sucedido desta técnica poderia ter permitido transferências arbitrárias de fundos e alterações disruptivas no livro-razão se fosse implementada em grande escala.

Além disso, a organização destacou o risco para a confiança mais ampla do ecossistema se tal exploração chegasse à mainnet. Hari Mulackal, CEO da Cantina e da Spearbit, comentou: “O nosso caçador de bugs autónomo, Apex, encontrou esta falha crítica.” As equipas de engenharia da Ripple reproduziram o comportamento com uma prova de conceito e concluíram um teste completo antes de resolver a falha.

Resposta de emergência e atualização rippled

Após a divulgação, os validadores UNL do XRPL foram prontamente aconselhados a votar “Não” na proposta em lote. Esta coordenação garantiu que a emenda não pudesse, por acidente, ultrapassar o limiar de ativação enquanto a correção estava em curso.

Foi lançada uma atualização de emergência do software, rippled 3.1.1, em 23 de fevereiro de 2026. Esta versão marca explicitamente tanto a emenda original em lote quanto a mudança relacionada fixBatchInnerSigs como não suportadas. Consequentemente, elas são bloqueadas de receber votos de validadores e não podem ser ativadas em qualquer rede de produção.

A versão de emergência não inclui a lógica final corrigida. Em vez disso, funciona como uma barreira de proteção, garantindo que nem o Batch nem o fixBatchInnerSigs possam alcançar a ativação na sua forma defeituosa. No entanto, esta medida imediata deu aos desenvolvedores tempo crucial para desenhar e revisar uma substituição mais segura.

Uma emenda corrigida, chamada BatchV1_1, foi agora implementada como sucessora do design original. Esta atualização elimina a saída precoce no processo de validação do signatário e reforça as verificações em todas as vias de autorização. A fundação confirmou que esta revisão ainda está em análise, sem data de implantação agendada.

Reforçar as práticas de segurança do XRPL

Após o incidente, a Fundação XRPL delineou medidas adicionais de segurança para fortalecer os fluxos de trabalho de desenvolvimento. Além disso, planeia expandir o papel da IA na revisão de alterações de protocolo para detectar erros de lógica subtis mais cedo no processo.

A organização pretende aumentar o uso de auditorias de código assistidas por IA, aproveitando o sucesso das ferramentas da Cantina AI e do sistema Apex neste caso. Também ampliará a análise estática para detectar especificamente padrões como retornos prematuros de sucesso dentro de loops, que contribuíram para a falha na lógica de validação do lote.

A fundação destacou que o episódio da emenda em lote do xrpl demonstra a importância de defesas em camadas, incluindo revisão humana, análise autónoma e ativação faseada. Combinando essas abordagens, os responsáveis pretendem reduzir o risco de vulnerabilidades não detectadas em futuras atualizações de protocolo.

Por fim, a Fundação XRPL enfatizou que a falha crítica foi corrigida antes da ativação na mainnet e antes de qualquer fundo ser comprometido. A deteção precoce, a resposta coordenada dos validadores e o lançamento rápido do rippled de emergência ajudaram a evitar transações não autorizadas e a preservar a integridade da rede XRPL.