Mecanismo de Consenso XRPL Contém Falha Crítica, Atacantes Podem Paralisar Rede de Validação - Já Corrigido

Empresa de pesquisa de segurança Common Prefix informou anteriormente à equipe Ripple sobre duas vulnerabilidades graves de segurança no XRP Ledger (XRPL), ambas relacionadas ao mecanismo de consenso dos nós de validação ao processar conjuntos de transações. Se a lista de nós únicos (UNL) for comprometida, o atacante pode enviar mensagens maliciosas, levando à falha em cadeia dos nós de validação. As correções já foram integradas na versão rippled 3.0.0.

Risco principal das vulnerabilidades: um nó comprometido pode afetar toda a rede

O mecanismo de consenso do XRPL exige que os nós de validação concordem sobre um conjunto de transações, trocando mensagens para estabelecer o consenso final. A origem das duas vulnerabilidades está na lógica do rippled ao lidar com “transações em disputa” (diferenças entre conjuntos de transações de diferentes nós).

A condição para o ataque é a invasão de um dos cerca de 35 nós na UNL. Embora esses nós geralmente fiquem ocultos atrás de nós proxy e comuniquem-se apenas com eles, dificultando a invasão, Nikolaos Kamarinakis, pesquisador da Common Prefix, afirma que não é impossível. Uma vez invadido, o atacante pode usar uma versão modificada do rippled para enviar continuamente mensagens maliciosas aos outros nós até que o nó comprometido seja removido da UNL.

Mecanismos técnicos das vulnerabilidades e soluções de correção

Vulnerabilidade 1 — Comparação de Transações: O nó comprometido afirma que uma transação existe na SHAMap, mas ela não está presente em um nó real. Outros nós tentam buscar a transação usando um ID inválido e falham, causando crash.

Correção 1: Adicionou-se uma etapa de validação para verificar se a transação realmente existe no nó indicado, evitando o crash causado por IDs inválidos.

Vulnerabilidade 2 — Encaminhamento de Transações: O nó comprometido envia um conjunto de transações maliciosas com hashes arbitrários. Outros nós identificam essas transações como em disputa e tentam retransmiti-las, levando a falhas ao executar verificações de “transações falsas” com dados inválidos.

Correção 2: Implementação de tratamento de exceções com try-catch para capturar erros causados por dados maliciosos, prevenindo a propagação de falhas.

A equipe do Ripple testou as correções em uma rede de testes isolada, reproduzindo com sucesso as vulnerabilidades e confirmando que, após aplicar as correções, os nós não mais travam ao receber mensagens maliciosas.

Confirmação das correções e roteiro de fortalecimento de segurança do XRPL

As correções foram integradas na versão rippled 3.0.0. Em testes, os nós atualizados permaneceram estáveis contra os mesmos vetores de ataque.

O Ripple anunciou um roteiro de fortalecimento de segurança do XRPL, incluindo ampliação de auditorias de segurança, uso de IA para revisão de código, realização de maratonas de segurança e aumento de recompensas por bugs para incentivar pesquisadores externos a reportar vulnerabilidades.

A Ripple agradece oficialmente à Common Prefix por sua divulgação responsável e colaboração técnica durante o processo de correção.

Perguntas frequentes

Qual a dificuldade real de atacar essas vulnerabilidades no XRPL?

É necessário invadir um dos cerca de 35 nós na UNL. Como esses nós geralmente ficam ocultos atrás de proxies e se comunicam apenas com eles, o vetor de ataque é limitado, mas não impossível. Portanto, é essencial aplicar as correções antes da divulgação pública.

Que ações os operadores de nós XRPL devem tomar?

Todos os operadores de nós com rippled 2.6.2 ou versões anteriores devem atualizar imediatamente para rippled 3.0.0 para garantir proteção completa contra essas vulnerabilidades. Versões anteriores correm risco de falhas em cadeia ao serem invadidas.

O que essas vulnerabilidades significam para a segurança a longo prazo do XRPL?

Elas demonstram a importância de um processo responsável de divulgação de vulnerabilidades. A Common Prefix reportou em junho de 2025, e a Ripple só divulgou publicamente após a correção em março de 2026. O roteiro de segurança inclui auditorias, uso de IA e aumento de recompensas, refletindo o compromisso contínuo com a segurança proativa.