A Bitcoin Red Team expandiu sua revisão de segurança assistida por IA para 501 projetos de código aberto relacionados ao Bitcoin, registrando 7.958 descobertas em sua última contagem detalhada após 108 horas de trabalho.
Calle, um desenvolvedor pseudônimo de Bitcoin envolvido no esforço, disse em 13 de agosto que a equipe já concluiu uma varredura básica de quase todo o ecossistema de código aberto do Bitcoin e que grande parte da superfície de vulnerabilidade mais fácil de encontrar já foi examinada.
Os números de destaque exigem uma distinção importante. As 7.958 descobertas não representam 7.958 vulnerabilidades exploráveis confirmadas. A equipe classificou 1.280 como de alta ou crítica, enquanto 24,7% de todas as descobertas foram reproduzidas dinamicamente e 29,4% foram reportadas aos mantenedores no marco de 108 horas. A revisão dos mantenedores e a reprodução humana continuam sendo parte do processo de verificação.
Calle disse que duas semanas de trabalho com o Kimi K3 da Moonshot AI expuseram a rapidez com que os modelos modernos podem examinar anos de código-fonte aberto acumulado. Ele descreveu a situação como uma “colisão massiva” entre software mais antigo e IA de ponta, acrescentando que “tudo está quebrado, o bitcoin está pegando fogo”. A formulação é sua caracterização e não deve ser lida como evidência de que o Bitcoin Core ou qualquer projeto Bitcoin está comprometido.
Testes independentes apoiam o ponto mais específico de que Kimi K3 possui uma capacidade significativa de cibersegurança. Uma avaliação conjunta do U.K. AI Security Institute e do U.S. CAISI descobriu que o modelo superou o GLM-5.2 em testes de desenvolvimento de exploits, mas permaneceu atrás dos modelos fechados mais fortes dos EUA. Kimi K3 marcou 32% no ExploitBench e alcançou execução arbitrária de código em zero das 41 amostras naquele teste.
Uma varredura anterior da Bitcoin Red Team encontrou 4.962 problemas potenciais em 390 projetos Bitcoin, incluindo 720 então classificados como de alta ou crítica. A contagem mais recente mostra que a revisão se expandiu materialmente após essa primeira onda.
A campanha avançou além da varredura automatizada. O lançamento oficial do BTCPay Server no GitHub creditou os pesquisadores da Bitcoin Red Team, Bruno Garcia e Ben Carman, por relatarem uma vulnerabilidade crítica que já estava sendo explorada. A versão 2.4.2 corrigiu um desvio de autenticação de dois fatores que afetava a Autenticação Básica Greenfield.
O BTCPay confirmou mais tarde que os atacantes haviam obtido credenciais LND admin macaroon de instalações afetadas e as usaram para acessar carteiras Lightning conectadas. O projeto disse que estava processando relatórios adicionais da Bitcoin Red Team, Project Loupe, Magic Grants e pesquisadores independentes, enquanto fortalecia seus processos de varredura e revisão.
Em 14 de agosto, o BTCPay anunciou outro release candidate focado em segurança, o v2.4.3-rc4, abordando vulnerabilidades relatadas por esses grupos. Em cobertura relacionada, os apoiadores do BTCPay apoiaram uma recompensa de recuperação após o exploit anterior e a fundação prometeu 0.21 BTC para o fundo da Bitcoin Red Team.
Essas correções fornecem evidências concretas de que os mantenedores estão validando pelo menos alguns relatórios sérios da Red Team. Elas não validam todos os itens no conjunto de dados de 7.958 descobertas. Auditorias assistidas por IA podem produzir falsos positivos, relatórios duplicados e avaliações de gravidade que mudam após investigação manual, tornando a verificação central para a interpretação dos números.
Calle argumentou que projetos sem manutenção devem agora ser tratados com maior cautela porque a IA reduziu drasticamente o custo de encontrar e testar vulnerabilidades. Ele também disse que o tempo de resposta está se tornando um indicador útil da saúde do projeto e que os mantenedores precisarão cada vez mais de seus próprios pipelines de auditoria contínua de IA, em vez de revisões externas ocasionais. Essas são as conclusões de Calle da campanha, e não regras de segurança universais.
O ecossistema mais amplo já está se movendo nessa direção. A OpenSats criou uma via de concessão de red-teaming de via rápida, focada parcialmente no reembolso de pesquisadores por custos de LLM. Mais de 40 organizações de Bitcoin e ativos digitais também pediram aos principais laboratórios de IA que concedam acesso controlado a modelos de ponta a defensores de código aberto verificados.
Conforme relatado pela crypto.news, a coalizão da indústria alertou que os desenvolvedores de Bitcoin poderiam ficar para trás dos atacantes sem acesso a modelos avançados de IA. O pedido não busca acesso irrestrito. Ele propõe pesquisadores verificados, ambientes seguros, capacidade de computação suficiente e canais de comunicação diretos com as equipes de segurança de IA.
A próxima fase provavelmente se moverá mais lentamente do que a varredura inicial. A descoberta automatizada pode escalar rapidamente, enquanto a reprodução, divulgação responsável, desenvolvimento de patches e testes de regressão exigem mais tempo. Os projetos que recebem relatórios devem determinar quais descobertas são exploráveis, com que urgência os usuários precisam de atualizações e quando os detalhes técnicos podem se tornar públicos com segurança.
Para os usuários de Bitcoin, a conclusão é mais restrita do que os números maiores sugerem. A Red Team relatou um grande volume de fraquezas potenciais em softwares relacionados ao Bitcoin, e não evidências de que o protocolo de consenso base do Bitcoin falhou. A preocupação de segurança imediata se concentra em carteiras, infraestrutura Lightning, software de pagamento e bibliotecas que contêm código mais antigo ou levemente revisado.
BTC