- Falha afeta cinco versões do Bitcoin Core e compromete modelos de blocos após reorganizações
- Correção chegou na versão 30.0, lançada em outubro de 2025
- Problema interrompe produção dos mineradores afetados até que seus nós sejam reiniciados
Uma vulnerabilidade no bitcoin Core compromete a produção de blocos por mineradores que usam determinadas versões antigas do software. Identificada como CVE-2025-62861, a falha aparece após reorganizações da blockchain e provoca a geração de modelos de blocos inválidos.
O problema alcança as versões 28.0, 28.1, 28.2, 29.0 e 29.1. Nos nós de mineração afetados, a interrupção persiste até o reinício do programa. A correção entrou na versão 30.0, lançada em outubro de 2025, e em atualizações posteriores com o ajuste.
Classificada como de alta gravidade, a vulnerabilidade envolve o tratamento de transações que retornam à fila de espera após uma reorganização. O defeito compromete a consistência dessa fila, usada pelos mineradores para selecionar as operações de seus próximos blocos.
Reorganização deixa transações sem dependência na fila
Uma reorganização ocorre quando o nó substitui parte da cadeia que acompanhava por outra com mais trabalho acumulado. Blocos antes aceitos deixam de integrar o histórico ativo. Suas transações podem voltar ao mempool, a área de operações ainda não confirmadas.
Nesse retorno, uma regra de substituição de transações permanecia ativa quando deveria estar desabilitada. O procedimento podia remover uma transação e preservar outras que dependiam dela. A fila passava, assim, a carregar uma relação de dependência inconsistente.
Considere uma operação que gasta a saída de outra. A segunda precisa aparecer antes da primeira no histórico válido de pagamentos. Sem essa condição, o conjunto selecionado para um bloco não atende às regras de validação.
Ao montar um bloco com essa combinação, o nó afetado produz um modelo inválido. Esse modelo orienta o trabalho dos equipamentos de mineração. O defeito está na preparação das transações, antes de um bloco válido chegar à rede.
A distinção técnica delimita o alcance da ocorrência: gerar um modelo inválido não faz os demais nós aceitarem suas transações. Cada participante verifica os blocos recebidos. A inconsistência local não altera automaticamente as regras compartilhadas de consenso.
Falha interrompe receita dos mineradores afetados
Para a operação de mineração, a consequência econômica decorre da indisponibilidade. Enquanto o nó não consegue fornecer um modelo válido, a estrutura vinculada a ele perde condições de produzir blocos aceitos e disputar as respectivas recompensas.
Desde o halving de abril de 2024, o subsídio por bloco é de 3,125 BTC, além das taxas das transações incluídas. Esse mecanismo permite dimensionar a receita disputada, mas não calcular perdas decorrentes da falha sem conhecer sua duração e o poder computacional envolvido.
O material divulgado não apresenta quantidade de mineradores atingidos, participação dessas versões no poder computacional ou estimativa de prejuízo. Também não informa episódios comprovados de exploração. A descrição técnica, isoladamente, não permite atribuir uma interrupção geral à rede.
A produção efetiva de blocos também depende da distribuição desse poder computacional. Em outro episódio, mineradores do CKPool encontraram dois blocos em sete horas. O resultado de operações individuais varia, mesmo quando seus sistemas funcionam normalmente.
Correção antecede fim do suporte à série 29.x
O cronograma separa a distribuição da correção da divulgação dos detalhes. A versão 30.0 já incorporava o reparo desde outubro de 2025. O último lançamento vulnerável da série 29.x encerrou seu período de manutenção em 27 de outubro de 2026.
Os detalhes vieram a público depois desse encerramento. O projeto mantém uma página de segurança para divulgar vulnerabilidades do cliente. A identificação CVE individualiza o defeito e permite distingui-lo de outras falhas com efeitos operacionais semelhantes.
Reiniciar o nó resolve a condição de bloqueio descrita, mas preserva o código vulnerável quando o operador mantém a mesma versão. A atualização que incorpora o reparo elimina a causa. Nas versões afetadas, outra reorganização ainda pode reproduzir a inconsistência no mempool.
