O Bitcoin Core alterou sua política de divulgação de segurança para acelerar a correção de vulnerabilidades facilmente encontradas por modelos de linguagem. Com isso, o projeto encerra os longos períodos de embargo antes aplicados a essa categoria de falha. A mudança busca reduzir o intervalo entre a descoberta do problema e a entrega de versões protegidas aos usuários.

Os mantenedores incorporaram a decisão à política de segurança do projeto na quinta-feira. No mesmo dia, Antoine Poinsot, desenvolvedor da Chaincode Labs, anunciou a atualização na lista de e-mails de desenvolvimento do Bitcoin. Segundo ele, os desenvolvedores receberam mais relatos de vulnerabilidades que outras pessoas poderiam redescobrir com pouco esforço.

Projeto muda tratamento de falhas redescobertas

O Bitcoin Core é o software utilizado pela maioria dos nós da rede Bitcoin. Até então, o projeto classificava cada vulnerabilidade relatada por gravidade e definia o prazo de divulgação conforme essa avaliação. Assim, falhas mais graves permaneciam em sigilo por períodos maiores.

Falhas de baixa gravidade se tornavam públicas duas semanas após o lançamento da versão principal seguinte. Por sua vez, problemas de gravidade média ou alta permaneciam sob embargo até duas semanas após o fim do suporte da última versão afetada. Em alguns casos, esse intervalo chegava a um ano.

A estratégia concedia mais tempo para operadores de nós instalarem versões protegidas antes da publicação dos detalhes. Na prática, porém, as versões antigas ainda mantidas não recebiam essas correções. As equipes disponibilizavam as mudanças apenas na próxima versão principal do software.

Correções chegarão mais rápido aos usuários

Poinsot argumentou que esse equilíbrio não funciona para bugs que qualquer pessoa consegue redescobrir facilmente. Durante a triagem, o Bitcoin Core poderá classificar uma vulnerabilidade como facilmente descobrível. Nesse contexto, a definição abrange problemas encontrados com esforço mínimo, inclusive por meio de um comando simples para um modelo de linguagem.

A categoria também poderá incluir falhas descobertas por outros meios. Para esses casos, o projeto levará a correção para todas as versões principais que ainda recebem manutenção. Em seguida, os responsáveis lançarão atualizações pontuais assim que possível.

Além disso, os desenvolvedores publicarão um aviso de segurança junto com o software corrigido. Contudo, Poinsot reconheceu que essas versões terão menos tempo de testes antes de chegarem aos usuários. Por isso, a nova abordagem troca parte do período de validação por uma resposta mais rápida.

Falhas críticas continuam sob avaliação individual

As vulnerabilidades que não entrarem na categoria de descoberta fácil seguirão o cronograma baseado em gravidade. Já os bugs críticos permanecerão fora da política padrão e receberão tratamento individual. Entre eles estão falhas capazes de permitir o roubo de bitcoins no nível do protocolo.

A categoria crítica também inclui problemas que possam inflar a oferta ou causar uma divisão permanente da cadeia. Antoine Riard sugeriu uma opção para lançar a correção sem aviso e reter os detalhes conforme cada situação. Por outro lado, Poinsot rejeitou a proposta por considerar que ela poderia gerar riscos desnecessários.

Na avaliação de Poinsot, um alerta sem detalhes poderia incentivar migrações apressadas entre usuários que não seriam afetados. A política revisada mantém a publicação simultânea do aviso e da atualização nos casos facilmente descobríveis. Enquanto isso, situações críticas continuarão sujeitas a decisões específicas dos mantenedores.

Relatos produzidos por IA aumentam pressão

A alteração ocorre após meses de pressão sobre projetos de código aberto ligados ao Bitcoin. No fim de julho, o Bitcoin Red Team reuniu 16 desenvolvedores e executou modelos de IA em 390 repositórios durante cerca de um dia. Ao todo, o grupo registrou 4.962 descobertas, das quais 85 receberam classificação crítica.

Poucos dias depois, invasores exploraram uma falha do BTCPay Server que o grupo havia relatado de forma privada. Nesse episódio, o ataque retirou fundos de nós da Lightning Network instalados em servidores ativos de comerciantes. Depois, em agosto, desenvolvedores do Core Lightning orientaram operadores a atualizar ou desconectar seus sistemas.

A recomendação surgiu após a confirmação de relatos gerados por IA e enviados ao projeto. A iniciativa do Bitcoin Red Team também ocorreu após uma exploração envolvendo carteiras físicas Coldcard. Em 30 de julho, os atacantes drenaram 594 BTC em 25 minutos.

As perdas em quatro operações se aproximaram de US$ 114 milhões. Dessa forma, a nova política pretende diminuir a exposição a falhas que ferramentas de IA podem revelar rapidamente. Ao mesmo tempo, o Bitcoin Core preserva a análise individual para vulnerabilidades com potencial de impacto crítico sobre o protocolo.

	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.