O Bitcoin Core revisou sua política de segurança para divulgar mais rapidamente vulnerabilidades fáceis de redescobrir. A mudança entrou em vigor em 22 de outubro. Agora, o projeto prevê correções simultâneas para todas as versões principais ainda mantidas.

Além disso, os responsáveis publicarão um alerta de segurança junto com as atualizações. A política não anunciou uma falha específica. Da mesma forma, um relatório produzido por inteligência artificial não representa automaticamente uma vulnerabilidade real.

A alteração trata do intervalo entre a confirmação técnica, a distribuição da correção e a divulgação pública. Os nós do Bitcoin validam blocos e transações localmente. Porém, o Bitcoin Core não atualiza automaticamente cada máquina.

Assim, um alerta pode ajudar operadores a instalar o patch. Ao mesmo tempo, ele pode oferecer pistas a invasores sobre nós desatualizados. Exchanges, custodiantes e outros serviços também estruturam operações sobre o software.

Política separa descoberta e gravidade da vulnerabilidade

O projeto já classificava falhas como críticas, altas, médias ou baixas. A análise considera os efeitos e as condições necessárias para a exploração. Por exemplo, uma falha que derruba remotamente um nó na configuração padrão pode receber gravidade alta.

Em contrapartida, um problema que exige configuração incomum pode ficar em uma categoria inferior. A política de alertas de segurança acrescentou outro critério: a facilidade para descobrir o problema. O documento cita como exemplo um comando simples enviado a um modelo de linguagem.

Contudo, a nova categoria não se limita a achados produzidos por inteligência artificial. Uma vulnerabilidade fácil de localizar não apresenta necessariamente baixa gravidade. Da mesma maneira, uma falha obscura pode causar danos sérios e exigir mais tempo de sigilo.

Durante a triagem, os mantenedores decidirão se o caso seguirá a rota acelerada. A política não estabelece um limite mecânico para ferramentas, comandos ou habilidades necessárias. Portanto, a equipe avaliará cada descoberta individualmente.

Correções alcançarão três versões mantidas

Para vulnerabilidades enquadradas nessa categoria, o Bitcoin Core pretende publicar atualizações pontuais para cada versão principal suportada. O projeto também divulgará um alerta no mesmo momento. Entretanto, a expressão “o mais rápido possível” não estabelece um prazo em horas.

Antes do lançamento, os desenvolvedores precisam confirmar o problema e criar o patch. Em seguida, eles revisam e testam a correção em cada ramificação. A equipe também precisa preparar e assinar os pacotes de atualização.

Antoine Poinsot afirmou na discussão da proposta que os mantenedores receberam mais relatos de falhas fáceis de redescobrir. Conforme explicou, modelos de linguagem reduziram o esforço necessário para localizar certos problemas. Essas ferramentas também podem encontrar correções que os desenvolvedores tentavam manter discretas.

Nesse cenário, reter detalhes oferece menos proteção quando terceiros conseguem localizar a fraqueza de forma independente. O ciclo de suporte cobre as três versões principais mais recentes. Com a versão 32.0 marcada em 21 de outubro, as ramificações 30.x, 31.x e 32.x permanecem nessa janela.

Já a versão 29.x e as anteriores chegaram ao fim de vida, conforme a página do ciclo de vida. Isso significa que o projeto não prepara novas correções para essas linhas. Apesar disso, cópias antigas podem continuar em operação.

Embargo tradicional pode superar um ano

As demais divulgações seguem outro calendário. Falhas de baixa gravidade chegam ao público duas semanas após uma versão principal que contenha a correção. Por sua vez, detalhes sobre problemas médios e altos podem aguardar o fim do suporte da última versão afetada.

Nesses casos, a publicação ocorre até duas semanas depois do fim de vida. Antes de revelar uma falha sob embargo, os mantenedores fazem um pré-anúncio com duas semanas de antecedência. O aviso informa quantas vulnerabilidades receberam correções e seus respectivos níveis de gravidade.

Enquanto isso, falhas críticas ficam fora desse cronograma. Cada uma exige uma resposta ajustada ao incidente. Dessa forma, a equipe pode coordenar patches e alertas conforme o risco imediato.

As notas da versão 32.0 registram três vulnerabilidades médias ou altas corrigidas na versão 30.0. Os detalhes devem chegar ao público duas semanas após a versão mais nova. A versão 30.0 data de 10 de outubro de 2025.

O cronograma da versão 32.0 registra a marcação em 21 de outubro de 2026. Portanto, o intervalo alcança 376 dias. As notas não identificam os componentes nem as condições de exploração das três falhas.

Na prática, uma correção pode estar disponível enquanto seus detalhes continuam privados. O sigilo permanece até as ramificações antigas deixarem a janela de manutenção. A rota acelerada muda esse cálculo apenas para problemas considerados fáceis de redescobrir.

Instalação depende de cada operador

Uma atualização disponível não significa que todos os nós estejam protegidos. Um usuário doméstico pode instalar a nova versão logo após o alerta. Por outro lado, uma exchange ou custodiante pode precisar testar a atualização antes de alterar sistemas de produção.

Esses testes podem envolver serviços internos, carteiras e ferramentas de monitoramento. O projeto recomenda a atualização de manutenção mais recente da versão principal que o operador consiga adotar. Ainda assim, empresas com integrações personalizadas podem precisar verificar a compatibilidade.

O fim de vida define o limite de suporte do projeto. No entanto, ele não desliga automaticamente programas antigos. Cada responsável decide quando substituir ou atualizar o software instalado.

A diferença entre ramificação e versão também importa. Um operador com as versões 30.0 ou 30.3 utiliza a linha 30.x. Contudo, os dois programas não contêm necessariamente as mesmas correções.

Desse modo, informar apenas o uso da “versão 30” não comprova proteção diante de um novo alerta. O operador precisa identificar a atualização pontual instalada. Depois disso, deve verificar se ela inclui o patch indicado.

Relatórios de IA ainda exigem validação

Ferramentas de inteligência artificial podem gerar muitas hipóteses. Mesmo assim, os mantenedores precisam validar cada uma delas. Em agosto, o Bitcoin Red Team informou 4.962 problemas potenciais em 390 projetos relacionados ao Bitcoin.

O levantamento ocorreu após 29,8 horas de revisão. O grupo classificou 720 achados como altos ou críticos. Também declarou ter reproduzido mais de um quinto dos problemas potenciais naquela data.

Esses números não representam uma contagem de falhas do Bitcoin Core. Tampouco indicam um total confirmado de bugs exploráveis. Um modelo pode sugerir um caminho no código, mas os desenvolvedores precisam demonstrar como um invasor conseguiria alcançá-lo.

Além do caminho de exploração, a equipe deve identificar quais versões sofrem impacto. Uma falha encontrada em ambiente de testes pode não existir em produção. Por isso, reprodução e análise continuam essenciais antes de qualquer alerta.

As instruções de reporte de segurança orientam o envio de descobertas sensíveis ao e-mail de segurança. O projeto desaconselha a abertura de uma issue pública nesses casos. Logo, a mudança não incentiva a publicação aberta de detalhes não verificados.

Alerta público divide desenvolvedores

Antoine Riard contestou a divulgação simultânea da correção e do aviso. Na discussão, ele argumentou que um alerta genérico pode incentivar migrações apressadas entre usuários não afetados. Um problema na montagem de blocos, por exemplo, pode exigir reação urgente dos mineradores.

Porém, a mesma falha pode não exigir uma ação imediata dos comerciantes. Poinsot respondeu que o sigilo prolongado pode manter versões antigas suportadas sem correção. As duas posições reconhecem que a implementação leva tempo.

Também existe consenso de que um alerta público altera o comportamento dos operadores. A divergência envolve qual risco prevalece em cada vulnerabilidade confirmada. O primeiro caso enquadrado na nova rota mostrará o ritmo real do processo.

Esse caso deverá incluir a classificação da falha, patches para três versões e lançamentos pontuais assinados. Também deverá apresentar um alerta de segurança. As notas da versão 32.0 orientam operadores a acompanhar a lista de anúncios para receber notificações sobre atualizações.

	Receba nossas últimas notícias em primeira mão.   Adicione-nos como sua fonte preferida no Google    e toque em “Favorito” para priorizar nossas atualizações.