Fundação XRP Ledger revela vulnerabilidade grave

A Fundação XRP Ledger divulgou uma vulnerabilidade séria em versões recentes da biblioteca JavaScript “xrpl.js”, amplamente usada para desenvolver aplicações que interagem com a rede XRP Ledger. O problema foi identificado pelo pesquisador de malware Charlie Eriksen, da Aikido Security, que classificou a falha como uma possível “ameaça catastrófica” de ataque na cadeia de suprimentos.

Backdoor e risco de roubo de chaves privadas

Segundo Eriksen, as versões comprometidas do pacote xrpl.js (v4.2.1 a v4.2.4 e v2.14.2) continham um backdoor que poderia permitir a hackers o acesso a chaves privadas de usuários. Isso colocaria em risco carteiras digitais e fundos, especialmente de projetos que atualizaram para essas versões entre 21 e 22 de abril.

Atualização de segurança urgente

A equipe do XRP Ledger já lançou a versão corrigida v4.2.5 e recomenda que todos os projetos afetados atualizem imediatamente. Em comunicado, a fundação esclareceu que o problema é exclusivo da biblioteca JavaScript distribuída via NPM (Node Package Manager) e não afeta o código principal do XRP Ledger hospedado no GitHub.

Impacto e precauções para desenvolvedores e usuários

O pacote afetado, com mais de 140 mil downloads semanais, é usado por centenas de milhares de sites e aplicações. Embora não haja confirmação de exploração ativa da vulnerabilidade, Eriksen alerta: “Caso você tenha utilizado essas versões, considere suas chaves comprometidas e mova seus ativos para uma nova carteira.”

XRP reage positivamente no mercado

Apesar da grave notícia, o token XRP registrou alta de 4% no dia 22 de abril, impulsionado pelo otimismo do mercado cripto mais amplo. Ainda assim, o episódio levanta questionamentos sobre a segurança de bibliotecas de código aberto utilizadas em ecossistemas financeiros descentralizados.

Como o ataque aconteceu

Atualização: em 28 de abril de 2025, a equipe do XRP Ledger publicou um relatório de divulgação do incidente com a linha do tempo completa. Segundo o documento, em 21 de abril, às 20h39 (UTC), um funcionário da Ripple responsável pela manutenção do pacote caiu em um golpe de phishing e entregou suas credenciais do npm. Entre 20h46 e 21h49 do mesmo dia, os invasores publicaram cinco versões maliciosas da biblioteca.

Na manhã de 22 de abril, às 8h14 (UTC), a Aikido Security alertou a Ripple. As medidas de contenção foram concluídas até as 12h34, e o caso se tornou público por volta do meio-dia. Como o código malicioso foi enviado direto ao npm, ele não passou pelo processo de revisão do repositório no GitHub, o que explica por que o código-fonte oficial não foi afetado.

O que o código malicioso fazia

Segundo a análise técnica da Aikido Security, as versões adulteradas traziam uma função chamada checkValidityOfSeed, embutida nos métodos de criação de carteira. Sempre que um aplicativo criava uma carteira ou gerava novas chaves com a biblioteca, a função enviava as chaves privadas e as seeds para um servidor controlado pelo atacante, em um domínio recém-registrado (0x9c[.]xyz). As versões foram publicadas pela conta mukulljangid no npm.

Além da versão 4.2.5 citada acima, a equipe também liberou a versão 2.14.3, que corrige a linha antiga da biblioteca. Quem usa a série 2.x deve atualizar para ela, e não apenas para a 4.2.5.

O que não foi afetado

O relatório do XRPL afirma que a rede XRP Ledger, o código do protocolo e os repositórios do GitHub não foram comprometidos. Até a publicação do relatório, nenhum efeito em aplicativos que usam a biblioteca havia sido relatado, e a equipe informou que estava entrando em contato com os projetos que dependem do pacote. A orientação para quem instalou alguma das versões comprometidas é tratar as carteiras como comprometidas e fazer a rotação das chaves.

Lições para quem usa carteiras e aplicativos

O caso mostra que um ataque pode chegar pelo software e não pela rede. Para o usuário comum, a regra prática é: se um aplicativo que você usou para criar ou importar uma carteira esteve exposto a uma biblioteca comprometida, a seed phrase daquela carteira deve ser considerada vazada. O caminho é criar uma carteira nova, com uma seed nova, e transferir os fundos. Trocar apenas a senha do aplicativo não resolve, porque quem tem a seed controla os ativos.

Para desenvolvedores, a recomendação da Aikido é identificar e remover as versões afetadas das dependências, monitorar conexões com o servidor do atacante e travar as versões das bibliotecas usadas em produção, evitando atualizações automáticas sem revisão.

E na declaração de imposto de renda?

Para quem está no Brasil, trocar de carteira depois de um incidente como esse não muda a forma de declarar, mas exige atualizar as informações. Segundo as Perguntas e Respostas do IRPF 2026 da Receita, o XRP é declarado no grupo 08, código 02 (a Receita cita o XRP como exemplo de altcoin), quando o custo de aquisição chega a R$ 5 mil. No campo de discriminação, o contribuinte informa a quantidade e onde o ativo está guardado: o nome da empresa com CNPJ ou custódia própria. Se os fundos saíram de uma exchange para uma carteira nova, vale registrar essa mudança e guardar os comprovantes das transferências.

Perguntas frequentes

Quais versões do xrpl.js foram comprometidas?

As versões 4.2.1, 4.2.2, 4.2.3, 4.2.4 e 2.14.2. As versões seguras são a 4.2.5 e a 2.14.3.

A rede XRP Ledger foi hackeada?

Não. Segundo o relatório oficial, o problema ficou restrito ao pacote distribuído no npm. A rede, o protocolo e os repositórios do GitHub não foram afetados.

O que fazer se usei um aplicativo com a versão afetada?

Considere as chaves comprometidas: crie uma carteira nova, com seed nova, e mova os ativos para ela o quanto antes.

Julia Santos

Contadora e editora-chefe do BTCnizando. Especialista em tributação de criptomoedas pela Faculdade Trevisan. Ajuda brasileiros a declarar Bitcoin no IR com segurança.