Pontos principais
- Bitcoin Core revelou esta semana três vulnerabilidades previamente corrigidas, sendo que uma delas poderia interromper a atividade de mineração.
- A falha mais grave poderia impedir que os nós afetados gerassem modelos de bloco válidos após uma reorganização da blockchain.
- Embora a instalação padrão não seja afetada, milhares de nós correm risco potencial devido a uma falha de configuração do Tor.
A vulnerabilidade mais importante foi identificada como CVE-2025-62861 e afeta as versões 28.0 a 28.2 e 29.0 a 29.1 do Bitcoin Core. Esta falha foi classificada como de alta severidade, envolvendo o processamento de transações durante reorganizações da blockchain, podendo impossibilitar que nós de mineração construam modelos de bloco válidos.
No seu cerne, estão as transações de versão 3, conhecidas como transações TRUC, que funcionam sob limites específicos de memória. Durante uma reorganização da cadeia, o Bitcoin Core pode expulsar transações incorretamente, mantendo dependências, o que provoca inconsistências no seu mempool.
Para os mineradores, as consequências são particularmente problemáticas. Nós afetados podem falhar na validação de modelos de bloco, impedindo-os de gerar novos trabalhos de mineração até que sejam reiniciados. Os equipamentos podem continuar a realizar hashing em modelos desatualizados, potencialmente perdendo taxas de transação e reduzindo a eficiência operacional.
O investigador de segurança Niklas Goegge reportou a falha a 26 de setembro de 2025. O programador Greg Sanders introduziu uma correção, que foi integrada a 2 de outubro, evitando a expulsão problemática de transações durante reorganizações.
A correção foi lançada nas versões 30.0, 29.2 e 28.3 do Bitcoin Core e mantida até outubro de 2025. Contudo, em torno da data de divulgação, cerca de 9% dos nós acessíveis ainda estavam a usar versões vulneráveis.
A segunda vulnerabilidade, CVE-2025-62859, foi classificada como de severidade média e envolve blocos compactos maliciosamente construídos. Atacantes poderiam explorar o processamento inadequado de witness de transações modificadas, adiando repetidamente o download de blocos. Sob determinadas condições de rede, incluindo pares de alta largura de banda comprometidos, a interferência poderia continuar indefinidamente.
O investigador Eugene Siegel identificou esta vulnerabilidade em abril de 2025. Gregory Sanders desenvolveu a correção, que chegou às versões 30.0 e 29.2 do Bitcoin Core.
Entretanto, o CVE-2025-62860 expôs um problema totalmente diferente, relacionado com ligações Tor de entrada e permissões de pares confiáveis. Quando operadores configuravam a definição opcional -whitelist do Bitcoin Core para incluir o endereço do seu daemon Tor, as ligações recebidas podiam herdar indevidamente privilégios destinados apenas a pares confiáveis.
Estas exceções enfraqueciam proteções contra ataques de negação de serviço e medidas de privacidade. O Bitcoin Core indica que milhares de nós de mainnet acessíveis podem ser afetados, embora a configuração padrão permaneça segura.
O anúncio de 10 de novembro segue o procedimento estabelecido de divulgação do Bitcoin Core. Os programadores retiveram detalhes técnicos até ao fim do ciclo de vida da última linha de lançamento principal vulnerável, 29.x (27 de outubro de 2026). Ao contrário das três divulgações de vulnerabilidades assistidas por IA de 28 de outubro, estes problemas seguiram o processo tradicional de embargo.
Importante referir que nenhuma destas vulnerabilidades permitiu roubo de Bitcoin, criação não autorizada de moedas ou falha de consenso, e nenhum aproveitamento foi identificado. A vulnerabilidade de mineração exige condições específicas de reorganização, limitando as consequências aos operadores afetados, e não ao Bitcoin como um todo.
Para mineradores de Bitcoin e administradores de nós, esta distinção é crucial. Mesmo que as vulnerabilidades não coloquem fundos em risco, a manutenção do software é fundamental. Este caso demonstra que pequenas falhas no processamento de transações podem causar problemas operacionais significativos sem comprometer o consenso de base da rede.
