O checksum foi trocado junto com o binário, e por 94 minutos a conferência de hash aprovou o malware

O que foi trocado não foi o código. A tag v0.15.0 continuou intacta, e quem instalou pelo proxy de módulos do Go ou compilou do repositório recebeu o programa certo. O que mudou foram os arquivos anexados à página de release: os pacotes prontos para macOS em arm64 e x86_64, Linux em arm64 e x86_64, Windows em x86_64, e o checksums.txt. Linux i386, Windows i386, Windows arm64 e a versão WASM ficaram de fora, o que parece escolha por volume de download e não varredura automática.

O próprio binário dizia que não havia saído da esteira oficial

A análise publicada pelo OpenSourceMalware rodou go version -m no pacote substituído, e o resultado não fecha com o processo de release do projeto. No lugar do número de versão aparece uma pseudoversão, v0.15.1-0.20261013083505-5ead8ef9b43d+dirty. O sufixo indica árvore com alteração não comitada. O ldflag que grava a versão não estava presente. E havia metadado de controle de versão embutido, que o GoReleaser remove quando compila com -trimpath.

Lido junto, isso descreve alguém rodando um go build comum na própria máquina, a partir de um commit que a v0.15.0 nunca teve, com código que os pesquisadores dizem não ter sido comitado em lugar nenhum. Não houve execução de GitHub Actions na janela da troca. O envio foi direto pela API de releases.

Reescrever o arquivo de somas muda a categoria do incidente

Conferir o hash do artefato contra a página de release é a recomendação que está em todo manual de instalação. Aqui ela aprovou o malware. O atacante trocou os pacotes e o arquivo de somas na mesma passada, então quem seguiu o procedimento recebeu confirmação de integridade. O pacote original ovhcloud-cli_Linux_arm64.tar.gz da v0.15.0 tinha SHA-256 iniciado em 5c2beb56; o substituído, em 3833daff. Nada na página apontava a diferença.

O que funcionou foi integridade guardada fora do canal de distribuição. A detecção veio da esteira de CI de um cliente que havia registrado o SHA-256 antes do ataque e comparou na execução seguinte. É a diferença entre confiar no publicador e ter referência própria.

Quem achou foi um cliente, e a falta de canal privado virou um segundo problema

A issue 300 foi aberta em público porque o repositório não tinha reporte privado de vulnerabilidade habilitado. O relato descrevia a substituição dos arquivos da v0.13.0 à v0.15.0, estranhava a conta que aparecia nas mudanças e registrava que o cliente havia passado a construir pelo proxy de módulos. Vale separar as duas contagens: a faixa de cinco versões, da v0.11.0 à v0.15.0, é a que a OVHcloud declarou como afetada, e a de três é o que o pesquisador conseguiu confirmar arquivo por arquivo. Na v0.11.0 e na v0.12.0 ele ficou com a palavra da empresa. Ou seja: o aviso de que cinco versões estavam comprometidas ficou visível para qualquer pessoa, inclusive para quem quisesse baixar os arquivos antes da remoção.

A linha do tempo em UTC, pela reconstrução do pesquisador: troca entre 12h47 e cerca de 13h12, issue aberta às 13h50, arquivos apagados às 14h21, v0.16.0 publicada às 17h16, como release imutável e com atestação. No fuso de Paris, que é o do aviso de Octave Klaba, isso dá 14h47 e 16h21. Noventa e quatro minutos.

A causa raiz é uma opção que não estava marcada

Klaba descreveu o problema com clareza incomum para o primeiro dia de um incidente: a imutabilidade de release não estava habilitada no repositório, então uma conta com permissão suficiente podia editar release já publicado direto na interface do GitHub. A opção foi ligada depois, e ele deu o caso por encerrado.

Fica um detalhe que não é pequeno. Pela documentação do GitHub, a imutabilidade não vale para trás. Da v0.10.0 à v0.15.0 o conjunto segue editável por quem tem escrita no repositório. As esteiras de CI e CD da OVHcloud não foram afetadas, e a imagem Docker oficial também não.

A trilha do GlassWorm existe, e ela para antes da atribuição

A conta usada, HassenBF, é de um contribuidor legítimo com permissão de escrita. Em março de 2026 vários repositórios pessoais desse desenvolvedor receberam um preinstall.js, script que roda durante o npm install e consulta a blockchain Solana para descobrir o endereço do servidor de comando. A carteira usada como ponto morto aparece em listas públicas de indicadores do GlassWorm.

Os pesquisadores foram honestos sobre o limite do que encontraram. Não há marcador de outras campanhas conhecidas e não há prova de que quem forçou o push em março é quem subiu os binários em outubro. A conta compartilhada é o único elo. Como a credencial foi obtida continua sem resposta pública.

O que ninguém vai saber

A OVHcloud apagou os arquivos antes que alguém arquivasse uma cópia, e o payload da CLI não foi analisado por terceiro. O que se tem é a descrição de Klaba: programa que busca segredo em disco, de qualidade ruim, suficiente para o serviço. Não há lista de caminhos lidos, nem endereço de exfiltração, nem hash do segundo estágio dessa amostra. Não há número de downloads. O carregador em AES com endereço guardado em memo da Solana, encontrado nos repositórios pessoais, é artefato separado, e os próprios pesquisadores não confirmam que ele estava no binário publicado.

Isso muda a decisão prática de quem foi atingido. Com lista de caminhos, a resposta é cirúrgica. Sem ela, a resposta é rotacionar tudo. O custo da ausência de análise forense cai inteiro no cliente.

A lição não depende da OVHcloud

Hash publicado ao lado do artefato, pelo mesmo publicador, no mesmo canal e editável pela mesma credencial, não é controle de integridade. É conveniência. O que resiste a esse tipo de ataque é atestação assinada, que se verifica fora do repositório, ou um registro próprio do hash feito antes, do jeito que o cliente que achou a troca tinha. A v0.16.0 saiu com as duas coisas. Elas estavam disponíveis antes do incidente, e a opção de ativar era de quem publica.