Visão Geral
Uma vulnerabilidade crítica do XRP Ledger que permaneceu no motor de pagamentos por aproximadamente uma década poderia, teoricamente, ter permitido que um atacante criasse XRP gastável além das regras de oferta pretendidas do ledger. A XRPL divulgou o problema em 9 de outubro de 2026, após ele ter sido relatado de forma privada através do Programa de Recompensas por Bugs da XRPL em 22 de setembro. A vulnerabilidade afetava o xrpld 3.4.0 e versões anteriores e foi corrigida no xrpld 3.4.1, lançado em 25 de setembro.
A vulnerabilidade do XRP Ledger envolvia um estouro de inteiro quando um pagamento consumia centenas de ofertas de livro de ordens especialmente construídas. Os proprietários individuais das ofertas podiam receber seus valores totais em XRP enquanto o comprador era cobrado apenas um pequeno total resultante do estouro. Mais gravemente, a invariante existente do ledger de “nenhum XRP criado” usava um caminho aritmético semelhante e poderia sofrer estouro da mesma forma, impedindo que essa verificação de segurança detectasse a discrepância.
A XRPL afirma que não encontrou evidências de que a vulnerabilidade tenha sido explorada em qualquer rede pública, e pagamentos normais não poderiam acioná-la acidentalmente. O ataque exigia ofertas deliberadamente projetadas com preços economicamente irrealistas. Mesmo assim, o incidente levanta uma questão de segurança mais profunda: a política monetária fixa de uma blockchain é tão forte quanto o software que aplica cada transição de saldo.
Principais Conclusões
- O bug parece ter existido desde que o atual motor de pagamentos da XRPL foi escrito em 2015.
- Uma transação deliberadamente construída poderia, teoricamente, ter criado XRP gastável.
- A XRPL não encontrou evidências de exploração em uma rede pública.
- A invariante de oferta existente poderia falhar porque reproduzia o mesmo comportamento de estouro.
- O
xrpld 3.4.1adicionou aritmética verificada e uma verificação de oferta independente mais forte.
O Que Era a Vulnerabilidade do XRP Ledger?
A vulnerabilidade estava dentro do tratamento de liquidez do livro de ordens pelo motor de pagamentos do XRP Ledger. Quando um pagamento passa por múltiplas ofertas, o motor precisa calcular quanto XRP o pagador deve no total. Cada valor individual poderia ser válido, mas o cálculo agregado usava um inteiro de 64 bits sem proteção suficiente contra estouro.
Em condições normais, isso era efetivamente inalcançável. A oferta normal de XRP e os preços reais de mercado não chegam nem remotamente perto do limite numérico necessário para estourar o contador. O problema surgia apenas quando um atacante construía deliberadamente centenas de ofertas nas quais cada conta pedia uma quantidade extremamente grande de XRP por uma quantidade minúscula de outro token.
Um fluxo malicioso poderia ser mais ou menos assim:
- Criar várias centenas de contas controladas.
- Colocar ofertas deliberadamente irrealistas a partir dessas contas.
- Construir um pagamento projetado para consumir essas ofertas em conjunto.
- Empurrar o cálculo agregado de XRP além do limite do inteiro.
- Fazer o total dar a volta para um número muito menor.
O motor poderia então creditar os proprietários das ofertas individualmente enquanto cobrava do comprador apenas o total resultante do estouro. Como o atacante também podia controlar as contas dos proprietários das ofertas, a diferença efetivamente se tornava novo XRP.
Os engenheiros da XRPL reproduziram o ataque localmente e confirmaram que o XRP resultante poderia subsequentemente ser transferido. O problema foi, consequentemente, elevado de Maior para severidade crítica.
A Vulnerabilidade do XRP Ledger Poderia Realmente Criar XRP?
Sim, teoricamente. Isso não era meramente um erro de exibição contábil. A divulgação técnica da XRPL diz que o exploit poderia ter criado XRP que se comportava como XRP comum após a transação maliciosa ser validada. Esses saldos poderiam ter sido movidos, negociados ou enviados para exchanges.
Isso não significa que o XRP foi historicamente emitido em excesso. A XRPL relata que não encontrou nenhuma evidência de que o exploit ocorreu em qualquer rede pública. A diferença entre essas duas afirmações é essencial: a vulnerabilidade poderia violar a restrição de oferta pretendida, mas atualmente não há nenhum evento histórico confirmado de oferta associado a ela.
O ataque também não poderia ocorrer acidentalmente durante a negociação normal na DEX. As ofertas do livro de ordens tinham que ser precificadas de forma tão irrealista que a liquidez normal de mercado seria executada antes de chegar a elas. Um pagamento também tinha que ser intencionalmente construído para consumir ofertas suficientes em conjunto para acionar o estouro.
Portanto, isso é melhor entendido como um caminho de execução de baixa probabilidade com impacto teórico extremamente alto, em vez de um erro que usuários comuns de XRP poderiam ter acionado sem saber.
Por Que a Verificação de Segurança de Oferta da XRPL Falhou?
A parte tecnicamente mais importante do incidente não é simplesmente que existia um estouro de inteiro. Software financeiro maduro frequentemente contém múltiplas camadas defensivas projetadas para capturar exatamente esse tipo de resultado inesperado.
A XRPL tinha uma: uma invariante de transação destinada a garantir que uma transação não pudesse criar XRP. Em princípio, mesmo que o motor de pagamentos cometesse um erro contábil, a invariante deveria ter notado que os saldos totais de XRP aumentaram e rejeitado a transação.
Não o fez.
A razão é uma falha clássica de sistemas de segurança supostamente independentes. A invariante calculava as mudanças líquidas de XRP usando um tipo semelhante de aritmética não verificada. Quando o mecanismo de pagamento transbordava, o cálculo da invariante podia transbordar na mesma direção, fazendo com que a transação resultante parecesse ter alterado o suprimento de XRP apenas pela taxa de transação comum.
Uma verificação de segurança não é verdadeiramente independente quando pode reproduzir o mesmo modo de falha que o sistema que está verificando.
Uma segunda proteção verificava se o saldo de uma conta individual excedia o suprimento total de XRP. Isso também falhou em impedir o ataque porque o XRP recém-criado podia ser distribuído por centenas de contas, mantendo cada saldo individual abaixo do limite.
A remediação, portanto, abordou tanto o bug imediato quanto a arquitetura defensiva. xrpld 3.4.1 adicionou verificações explícitas de transbordamento quando os valores são agregados entre ofertas e caminhos de pagamento. O XRPL também alterou a invariante de nenhum-XRP-criado para usar um contador mais amplo que não pode dar a volta sob as mesmas condições.
Por que um bug de 2015 permaneceu oculto por tanto tempo?
A resposta está em parte na diferença entre valores econômicos realistas e limites teóricos de computadores. Pagamentos individuais de XRP operam muitas ordens de magnitude abaixo do intervalo necessário para transbordar uma soma de 64 bits. Um trader normal poderia usar o XRPL por anos sem criar nada que se assemelhasse às condições numéricas maliciosas.
Isso tornou a falha difícil de expor por meio do uso rotineiro. A lógica vulnerável podia se comportar corretamente em bilhões de operações normais enquanto ainda falhava catastroficamente em uma fronteira artificial.
A vulnerabilidade também demonstra por que código blockchain de longa duração não deve ser automaticamente considerado seguro simplesmente porque operou por muitos anos. O histórico de produção é evidência útil, mas testa principalmente estados comuns. Atacantes procuram deliberadamente estados que usuários normais nunca criam.
O XRPL creditou seu Programa de Recompensas por Bugs por encontrar o problema e delineou uma abordagem mais ampla de defesa em profundidade que inclui auditorias independentes, atacathons públicos, fuzzing, red teaming assistido por IA e verificação formal. Também está adicionando reverificação de correções de segurança contra candidatos a lançamento antes que as descobertas sejam formalmente encerradas.
Essa abordagem importa porque a lição deste incidente não é que código maduro não pode ser confiável. É que código maduro ainda requer testes adversariais contra suposições que os desenvolvedores pararam de questionar anos antes.
O que o bug significa para o suprimento fixo de XRP?
O XRP começou com um suprimento inicial definido de 100 bilhões de tokens, sem mecanismo de protocolo análogo à mineração de prova de trabalho que cria continuamente XRP adicional. As taxas de transação são destruídas em vez de pagas aos validadores, então o caminho de suprimento pretendido é não inflacionário.
A vulnerabilidade do XRP Ledger expõe uma distinção importante entre política monetária como regra e política monetária como aplicação de software.
Uma especificação de blockchain pode declarar que novo XRP não pode ser criado, mas os nós, em última análise, aplicam essa propriedade por meio de código. Se a lógica de transição de saldo puder ser manipulada para violar a regra, então a própria política econômica pode falhar mesmo que a política documentada não tenha mudado.
Este incidente não demonstrou que o suprimento circulante real de XRP foi secretamente aumentado. O XRPL afirma que nenhuma exploração da rede pública foi encontrada. Mas demonstrou que, antes do patch, havia um caminho de execução teórico capaz de contornar uma das restrições monetárias mais fundamentais do ledger.
Isso torna essa vulnerabilidade mais consequente do que uma interrupção temporária de RPC ou um problema de conectividade de nó. Uma rede pode tolerar certas interrupções de infraestrutura sem comprometer a integridade do ativo. Um bug capaz de gerar unidades gastáveis toca a fundação contábil do próprio ledger.
Por que a correção importa mais do que a ausência de um exploit
É tentador descartar uma vulnerabilidade depois que os investigadores dizem que ela nunca foi explorada. Isso perderia a lição de segurança mais útil.
A linha do tempo de resposta do XRPL foi relativamente comprimida: o problema foi relatado e reproduzido em 22 de setembro, a correção foi desenvolvida e revisada entre 22 e 23 de setembro, mesclada no ramo de lançamento 3.4.1 e lançada em 25 de setembro. O XRPL relatou que mais de 80% dos validadores padrão da Lista de Nós Únicos estavam executando a versão protegida no mesmo dia.
A correção do mecanismo de pagamento também entrou em vigor diretamente com a atualização de software, em vez de esperar pelo processo normal de ativação de emenda. Isso foi possível porque rejeitar o transbordamento aritmético foi tratado como correção de comportamento indefinido ou inseguro, em vez de introduzir uma nova regra de transação pretendida.
Para a segurança da blockchain, o momento da divulgação faz parte da defesa. Publicar a exploração antes que os validadores estivessem protegidos teria transformado uma vulnerabilidade teórica em instruções operacionais para atacantes. A XRPL, portanto, divulgou os detalhes técnicos depois que a versão corrigida já havia se propagado.
Riscos e Limitações
O incidente é grave, mas várias fronteiras devem permanecer claras.
- Nenhum evento de inflação confirmado: a XRPL afirma não ter encontrado evidências de exploração em uma rede pública.
- Nenhum acionamento acidental: pagamentos normais e livros de ofertas realistas não atingem os valores necessários.
- A adoção do patch é importante: espera-se que os operadores de servidores executem o
xrpld 3.4.1ou mais recente. - Uma correção não prova segurança completa: outras antigas suposições aritméticas ainda merecem testes adversariais.
- A ausência histórica de abuso não pode substituir a verificação formal: algumas classes de bugs são incomuns demais para surgir por meio da atividade normal da rede.
Outra limitação é a certeza retrospectiva. Os investigadores podem analisar o histórico do ledger e padrões de exploração conhecidos, mas provar que uma vulnerabilidade nunca foi usada é inerentemente diferente de provar matematicamente que ela não poderia ter sido usada. A conclusão oficial é, portanto, adequadamente formulada como nenhuma evidência encontrada, em vez de uma afirmação absoluta sobre cada estado histórico.
Visão da MEXC: O Fornecimento Fixo É uma Propriedade de Segurança de Software
A política monetária de uma blockchain não é garantida apenas por um número de fornecimento escrito na documentação. Ela é garantida pelo software que valida cada alteração de saldo, caminho de transação e estado do ledger.
O incidente da XRPL ilustra por que essa distinção é importante. A regra pretendida pelo protocolo proibia a criação de novos XRP, mas uma falha na aritmética poderia, teoricamente, ter violado essa regra. Mais importante ainda, a invariante defensiva projetada para detectar a criação de fornecimento inicialmente compartilhava o mesmo modo de falha.
Para redes blockchain maduras, a segurança, portanto, precisa ir além de testar se as transações normais se comportam corretamente. Invariantes independentes, fuzzing, testes adversariais de limites e métodos formais tornam-se cada vez mais importantes precisamente porque as vulnerabilidades mais prejudiciais podem existir em caminhos de código que os usuários comuns nunca tocam.
A métrica que vale a pena observar após esta divulgação não é a reação do preço do XRP. É se os processos de verificação expandidos da XRPL encontram e isolam consistentemente classes semelhantes de risco latente de protocolo antes que os atacantes o façam.
O Bug de Uma Década Era Crítico, Não um Evento Comprovado de Inflação do XRP
A vulnerabilidade do XRP Ledger merece a descrição de “crítica” porque poderia, teoricamente, ter minado uma das garantias mais fundamentais da XRPL. Um pagamento cuidadosamente projetado poderia forçar um estouro aritmético de 64 bits, creditar centenas de proprietários de ofertas com XRP e cobrar do comprador apenas uma fração do valor agregado. Os saldos recém-criados eram gastáveis na própria reprodução do ataque pela XRPL.
Mas a segunda metade da história é igualmente importante. A XRPL não encontrou nenhuma evidência de exploração em rede pública, a transação exigia condições de livro de ofertas deliberadamente anormais, e a vulnerabilidade foi corrigida no xrpld 3.4.1 antes que os detalhes técnicos fossem divulgados publicamente.
O incidente, portanto, não deve ser reescrito como evidência de que o fornecimento de XRP foi historicamente inflado. Seu significado é mais estrutural. Ele mostra que até mesmo uma blockchain de fornecimento fixo depende, em última análise, de o software impor corretamente as restrições monetárias em casos extremos que podem permanecer invisíveis por anos.
A conclusão mais forte desta vulnerabilidade do XRP Ledger é, consequentemente, sobre engenharia de protocolo, e não sobre manchetes de fornecimento de tokens. Invariantes monetárias precisam de implementação independente, código antigo ainda requer revisão adversarial, e a operação bem-sucedida da rede ao longo de uma década não elimina a possibilidade de falhas ocultas em condições de contorno. O bug não provou que o XRP havia sido emitido em excesso; provou por que a integridade do fornecimento deve ser continuamente verificada.
Fontes
Divulgação oficial de vulnerabilidade da XRPL:
https://xrpl.org/es-es/blog/2026/vulnerabilitydisclosurereport-bug-20261009
Informações de lançamento do XRPL 3.4.1:
https://xrpl.org/blog
Quer obter as últimas notícias da MEXC o mais rápido possível? Junte-se agora ao nosso grupo oficial do Telegram!
Plataforma MEXC: Baixar o App | Negociação com taxa zero | Compre USDT agora Junte-se à comunidade MEXC: X (Twitter) | Telegram | Discord
Obtenha informações: Academia para Iniciantes | Termos de Serviço | MEXC Blog | MEXC News
Verificação de conta: Entenda o KYC | Como fazer o KYC
Aviso de risco: O conteúdo deste artigo é apenas para referência e não constitui qualquer conselho de investimento. O mercado de moedas digitais é bastante volátil, tome decisões com cautela de acordo com a sua própria situação.
