XRPL Corrige Bug Crítico na Lote de Emenda que Poderia Ter Drenado Fundos, Descoberto por Ferramenta de Segurança AI

A XRP Ledger Foundation confirmou a 26 de fevereiro de 2026 que uma vulnerabilidade crítica na lógica de validação de assinaturas da emenda proposta para o Batch foi identificada e corrigida antes da ativação, evitando um potencial exploit que poderia ter permitido aos atacantes executar transações não autorizadas e drenar fundos sem acesso às chaves privadas das vítimas.

Descoberta pela engenheira de segurança Pranamya Keshkamat e pela ferramenta de segurança autónoma de IA Apex da Cantina a 19 de fevereiro, a falha foi corrigida através de um lançamento de emergência da versão rippled 3.1.1 a 23 de fevereiro, sem fundos em risco, pois a emenda permaneceu em fase de votação e nunca foi ativada na mainnet.

Cronologia de Descoberta e Divulgação

A 19 de fevereiro de 2026, foi identificada uma falha lógica crítica no código de validação de assinaturas da proposta emenda por lote para o XRP Ledger. A vulnerabilidade foi descoberta através de uma análise estática da base de código ondulada por Pranamya Keshkamat, engenheira de segurança na empresa de cibersegurança Cantina, em conjunto com a ferramenta de segurança autónoma de IA da Cantina, Apex.

A equipa de descoberta submeteu prontamente um relatório responsável de divulgação à Fundação XRPL, permitindo que as equipas de engenharia da Ripple validassem a descoberta com uma prova de conceito independente e uma reprodução completa por teste unitário. Os esforços de remediação começaram na mesma noite.

Hari Mulackal, CEO da Cantina e da Spearbit, afirmou que “o nosso caçador de bugs autónomo, Apex, encontrou este bug crítico”, acrescentando que “se isto tivesse sido explorado, teria sido o maior ataque de segurança em valor monetário do mundo, com quase 80 mil milhões de dólares em risco direto”, referindo-se à capitalização bolsista da XRP.

Natureza Técnica da Vulnerabilidade

A vulnerabilidade residia na lógica de validação de assinaturas da emenda Batch, uma funcionalidade proposta que permitiria a execução atómica de até oito transações numa única operação batch. Quando ativadas, as transações internas num lote são intencionalmente sem assinatura, com a autorização delegada inteiramente à lista de signatários do lote externo.

A causa raiz foi um erro crítico de loop na função responsável por validar esses signatários. Quando o validador encontrava um signatário cuja conta ainda não existia no registo e cuja chave de assinatura correspondia à sua própria conta — o caso normal numa conta nova — declarava imediatamente sucesso e saía, saltando completamente a validação de todos os assinantes restantes.

Esta falha criou um caminho claro de exploração: um atacante podia construir uma transação em lote contendo três transações internas — uma criando uma nova conta que controla, uma transação simples dessa nova conta (tornando-a assinante obrigatória) e um pagamento de uma conta vítima para o atacante. Ao fornecer duas entradas de lote de assinaturas — uma legítima para a nova conta e uma falsa que afirmava autorizar a conta da vítima mas assinada com a própria chave do atacante — a validação saía com sucesso após a primeira entrada e nunca validava a segunda, permitindo que o pagamento da vítima fosse executado sem que as suas chaves estivessem envolvidas.

Impacto Potencial e Remediação

Se a emenda do lote tivesse sido ativada antes do bug ser detetado, um atacante poderia ter roubado fundos ao executar transações internas de pagamento, esvaziando as contas das vítimas para a reserva, modificado o estado do livro razão através de transações não autorizadas no AccountSet, TrustSet ou AccountDelete, e potencialmente desestabilizado o ecossistema mais amplo através da perda de confiança no XRPL.

Após a confirmação da vulnerabilidade, os validadores da UNL foram imediatamente contactados e aconselhados a votar contra a emenda do Batch. A versão de emergência rippled 3.1.1 foi publicada a 23 de fevereiro de 2026, marcando tanto o Batch como o fixBatchInnerSigs como não suportados, impedindo-os de receber votos de validadores ou de serem ativados na rede.

Uma emenda de substituição corrigida, BatchV1_1, foi implementada com a correção lógica completa que removeu a condição de saída antecipada, adicionou proteções adicionais de autorização e restringiu o âmbito da verificação de assinatura. Esta substituição está atualmente a passar por uma revisão minuciosa antes do lançamento, sem um prazo definido ainda.

O Papel Emergente da IA na Cibersegurança

A descoberta destaca o papel crescente da inteligência artificial nas aplicações de cibersegurança. A Apex, a ferramenta autónoma de segurança de IA da Cantina, identificou a vulnerabilidade através de uma análise estática da base de código, demonstrando a capacidade da IA para detetar bugs subtis que possam passar despercebidos pelos revisores humanos.

Este incidente coincide com desenvolvimentos mais amplos da indústria em segurança alimentada por IA. A 20 de fevereiro, a Anthropic lançou o Claude Code Security, um scanner de vulnerabilidades de cibersegurança com IA que a empresa afirma “conseguir raciocinar como um investigador de segurança habilidoso.” O surgimento destas ferramentas sinaliza uma possível mudança na forma como as vulnerabilidades das infraestruturas críticas são identificadas e abordadas.

Resposta da Fundação XRPL e Medidas Futuras

A Fundação XRPL delineou um roteiro de melhorias de segurança em resposta ao incidente, incluindo a adição de pipelines de auditoria de código assistida por IA como etapa padrão no processo de revisão, a extensão da cobertura de análise estática para sinalizar retornos prematuros de sucesso dentro dos ciclos de iteração do signatário, a adição de comentários explícitos e asserções invariantes que documentam o comportamento esperado para contas não criadas no momento da validação, e a revisão de todas as outras localizações da base de código onde retornos de sucesso antecipados ocorrem dentro dos ciclos para confirmar que não existem padrões semelhantes.

A fundação também anunciou um reset de devnet agendado para 3 de março de 2026, para acomodar as alterações e evitar que validadores que atualizem fiquem bloqueados por alterações. O reset apaga todos os dados do livro de registo devnet, incluindo contas, transações, saldos e outros registos, com todos os saldos a serem reiniciados a zero e o número do bloco a reiniciar a um. Mainnet, XRPL Testnet, Xahau e a testnet Hooks continuarão as operações normais sem serem afetados.

FAQ: Compreensão da Vulnerabilidade da Emenda de Lote XRPL

P: O que deveria fazer a emenda do Batch no XRP Ledger?

R: A emenda de lote foi uma funcionalidade proposta que permitia a execução atómica de até oito transações numa única operação de lote. Teria permitido aos programadores criar aplicações com funcionalidades pagas, fluxos de trabalho automatizados e modelos diretos de receitas on-chain, garantindo que múltiplas transações executadas em conjunto tivessem sucesso ou todas falhassem.

P: Como poderiam os atacantes ter explorado esta vulnerabilidade?

R: Os atacantes poderiam ter construído uma transação em lote com um pagamento criando uma nova conta, uma transação a partir dessa conta e um pagamento a partir de uma conta vítima. Ao explorar uma falha em que a validação saía cedo ao encontrar um signatário de uma conta inexistente, podiam contornar verificações de assinatura no pagamento da vítima e drenar fundos sem nunca possuírem as chaves privadas da vítima.

P: Porque não se perdeu dinheiro neste incidente?

R: A emenda do Batch ainda estava na fase de votação e não tinha sido ativada na mainnet quando a vulnerabilidade foi descoberta. A Fundação XRPL aconselhou imediatamente os validadores a votar contra a emenda e emitiu uma versão de software de emergência (rippled 3.1.1) desativando-a completamente, impedindo qualquer possibilidade de ativação.

P: Que papel desempenhou a IA na descoberta desta vulnerabilidade?

R: A ferramenta autónoma de segurança de IA da Cantina, Apex, identificou a vulnerabilidade através de uma análise estática da base de código ondulada. A descoberta da IA, combinada com a análise de um engenheiro de segurança humano, permitiu uma divulgação responsável e a aplicação de correções antes que a alteração pudesse ser ativada, demonstrando a crescente importância das ferramentas de cibersegurança baseadas em IA.