#XRP账本修复可增发XRP的漏洞
$XRP Essa vulnerabilidade era tão grave que, para corrigi-la, foi preciso pular a votação habitual.
Em 9 de outubro de 2026, a XRPL revelou uma vulnerabilidade que remontava a 2015 e permitia criar XRP do nada, que poderia ser gasto. Segundo a equipe, ainda não havia indícios de que ela tivesse sido explorada na rede pública.
O processo era bastante absurdo. Ao somar o valor dos pedidos no sistema de pagamentos, os números ficavam grandes demais e o resultado do cálculo dava a volta, tornando-se um valor pequeno. Os vendedores recebiam o valor original, mas dos compradores só era debitado o troco — e a diferença virava XRP novo. Até o programa responsável por verificar se havia “emissão adicional” usava o mesmo método de cálculo e também errava. A equipe de desenvolvimento já reproduziu o problema em testes locais.
Se alguém explorasse a falha antes da correção e transferisse as moedas criadas para uma corretora, os demais detentores poderiam enfrentar pressão adicional de venda e diluição da oferta. Manter as moedas em uma carteira fria também não protegeria contra esse risco para o preço.
Em 25 de setembro, foi lançada a versão corrigida 3.4.1. Na época, os desenvolvedores optaram por não divulgar o código-fonte imediatamente e pediram que os nós a instalassem o quanto antes. Em seguida, Justin Bons, fundador da Cyber Capital, criticou duramente essa decisão no X e questionou o compromisso do projeto com a descentralização.
Consigo entender a urgência dessa correção: divulgar o código corrigido exporia a vulnerabilidade, enquanto seguir o processo habitual de votação exigiria esperar pela ativação — o que deixaria uma janela para os atacantes.
O preço disso é que os nós precisam confiar primeiro em quem publicou a atualização e, por enquanto, não conseguem analisar completamente o código-fonte dessa versão. Durante a atualização, se as versões antiga e nova se depararem com uma transação de ataque, também podem divergir e até interromper a rede. O relatório de divulgação reconheceu esse risco, e o código-fonte já está público.
O risco de emissão adicional, já reproduzido, é grave o suficiente. Mas esse tipo de medida emergencial precisa ser explicado a cada ocorrência e passar por uma revisão posterior. O fato de os nós aceitarem colaborar uma vez não significa que devam fazer o mesmo automaticamente em todas as ocasiões futuras.
#xrp #Ripple #加密货币
$XRP Essa vulnerabilidade era tão grave que, para corrigi-la, foi preciso pular a votação habitual.
Em 9 de outubro de 2026, a XRPL revelou uma vulnerabilidade que remontava a 2015 e permitia criar XRP do nada, que poderia ser gasto. Segundo a equipe, ainda não havia indícios de que ela tivesse sido explorada na rede pública.
O processo era bastante absurdo. Ao somar o valor dos pedidos no sistema de pagamentos, os números ficavam grandes demais e o resultado do cálculo dava a volta, tornando-se um valor pequeno. Os vendedores recebiam o valor original, mas dos compradores só era debitado o troco — e a diferença virava XRP novo. Até o programa responsável por verificar se havia “emissão adicional” usava o mesmo método de cálculo e também errava. A equipe de desenvolvimento já reproduziu o problema em testes locais.
Se alguém explorasse a falha antes da correção e transferisse as moedas criadas para uma corretora, os demais detentores poderiam enfrentar pressão adicional de venda e diluição da oferta. Manter as moedas em uma carteira fria também não protegeria contra esse risco para o preço.
Em 25 de setembro, foi lançada a versão corrigida 3.4.1. Na época, os desenvolvedores optaram por não divulgar o código-fonte imediatamente e pediram que os nós a instalassem o quanto antes. Em seguida, Justin Bons, fundador da Cyber Capital, criticou duramente essa decisão no X e questionou o compromisso do projeto com a descentralização.
Consigo entender a urgência dessa correção: divulgar o código corrigido exporia a vulnerabilidade, enquanto seguir o processo habitual de votação exigiria esperar pela ativação — o que deixaria uma janela para os atacantes.
O preço disso é que os nós precisam confiar primeiro em quem publicou a atualização e, por enquanto, não conseguem analisar completamente o código-fonte dessa versão. Durante a atualização, se as versões antiga e nova se depararem com uma transação de ataque, também podem divergir e até interromper a rede. O relatório de divulgação reconheceu esse risco, e o código-fonte já está público.
O risco de emissão adicional, já reproduzido, é grave o suficiente. Mas esse tipo de medida emergencial precisa ser explicado a cada ocorrência e passar por uma revisão posterior. O fato de os nós aceitarem colaborar uma vez não significa que devam fazer o mesmo automaticamente em todas as ocasiões futuras.
#xrp #Ripple #加密货币