Segurança · 22 de outubro de 2026

Atacantes Comprometem Cinco Lançamentos da CLI da OVHcloud para Distribuir Malware de Roubo de Segredos

gray and black laptop computer on surface
Ales Nesetril / Unsplash

Um atacante utilizou uma conta de contribuidor do GitHub para substituir os arquivos de download em cinco lançamentos existentes da ferramenta de linha de comando da OVHcloud na segunda‑feira, 19 de outubro. A conta havia sido comprometida e os novos arquivos foram construídos para roubar segredos armazenados no disco de qualquer máquina que os executasse, afirmou o provedor de nuvem.

Os arquivos permaneceram disponíveis no GitHub por até 94 minutos, entre 12h47 e 14h21 UTC, e afetaram apenas quem instalou ou atualizou a CLI da OVHcloud nesse intervalo, por meio de um caminho que verifica a ausência de hash, nas plataformas macOS, Linux x86_64 ou arm64, ou Windows x86_64.

A OVHcloud removeu os arquivos substituídos e publicou a versão limpa v0.16.0 como um lançamento imutável, cujo conteúdo o GitHub não permite que seja alterado. O código‑fonte, a tag de lançamento e a pipeline de construção da empresa não foram alterados: o binário malicioso foi construído a partir de um commit posterior e foi enviado diretamente aos lançamentos publicados entre 14 de abril e 16 de setembro.

Na versão v0.15.0, o atacante substituiu seis arquivos: os arquivos de arquivos para macOS x86_64 e arm64, para Linux x86_64 e arm64, para Windows x86_64 e o arquivo checksums.txt, de modo que os hashes publicados coincidissem com os novos binários. Os mesmos seis arquivos foram removidos dos lançamentos v0.11.0 até v0.14.0. Os builds para Linux i386, Windows i386, Windows arm64 e WebAssembly foram deixados intactos em todos os lançamentos.

A OVHcloud classifica v0.11.0 até v0.15.0 como comprometidos e v0.10.0 como limpo. Esses cinco lançamentos foram publicados entre 14 de abril e 16 de setembro, portanto, uma cópia instalada antes de 12h47 UTC na segunda‑feira e que não foi atualizada desde então corresponde ao lançamento original.

Um usuário obteve um arquivo trocado se, nesse intervalo e em uma das plataformas suportadas, ele:

O cliente que detectou a troca extraiu informações de construção do binário Linux arm64 da nova versão v0.15.0 usando o comando go version -m, que lê o arquivo sem executá‑lo, e postou o resultado em um problema no GitHub. Três características marcam o build malicioso:

A orientação que circula indica que qualquer build marcado como +dirty ou que contenha linhas de VCS sinaliza o build da OVHcloud como malicioso. O Hacker News executou o mesmo comando no binário limpo v0.16.0 para Linux x86_64 e obteve v0.16.0+dirty, vcs.modified=true e o commit de origem.

O único hash publicado de um arquivo trocado corresponde ao arquivo de arquivos para Linux arm64 da versão v0.15.0:

Um build sem a flag de versão reporta sua versão como indefinida, mas executar um binário suspeito para descobrir sua versão não é recomendável.

O fundador da OVHcloud, Octave Klaba, escreveu no X na noite de segunda‑feira que os afetados devem mudar todos os segredos armazenados no disco. A CLI da OVHcloud mantém as credenciais da API da empresa em ~/.ovh.conf e as lê de variáveis de ambiente, conforme a documentação, e a orientação abrange todo o conteúdo do disco, não apenas esses arquivos.

A OVHcloud não divulgou quais arquivos o binário lê, para onde os envia ou quantas cópias foram baixadas, e nenhum arquivo trocado foi analisado publicamente. A empresa prometeu um relatório detalhado nos próximos dias.

Qualquer pessoa com acesso de gravação a um repositório GitHub pode excluir os arquivos anexados a um lançamento e fazer upload de novos com os mesmos nomes, e a URL de download não muda a menos que a imutabilidade do lançamento esteja habilitada.

O recurso de imutabilidade, disponibilizado desde outubro de 2025, bloqueia a modificação dos arquivos e da tag de um lançamento, protegendo apenas os lançamentos criados após sua ativação.

A OVHcloud não havia ativado esse recurso. Em uma segunda postagem na noite de segunda‑feira, citada pelo Next, Klaba afirmou que o problema decorreu da opção de imutabilidade não estar ativada, permitindo que um usuário com permissões adequadas modificasse lançamentos existentes diretamente no GitHub sem verificações pela pipeline CI/CD da empresa. O recurso foi ativado e as pipelines não foram afetadas.

Os cinco lançamentos antigos agora oferecem apenas os quatro arquivos que o atacante não alterou.

Os uploads foram realizados através da conta de um contribuidor cujas contribuições estão no repositório de documentação da OVHcloud e que não é membro público da organização, segundo o OpenSourceMalware, que construiu uma linha do tempo a partir dos registros do servidor do GitHub.

O fluxo de lançamento nunca foi executado: a lista de execuções não mostra nenhum workflow entre 16 de outubro e a tag v0.16.0 publicada às 16h00 UTC na segunda‑feira. As primeiras verificações não identificaram outros repositórios afetados, escreveu Klaba em sua primeira postagem, e a OVHcloud ainda não informou como as credenciais da conta foram comprometidas.

Um trabalho CI de um cliente detectou a troca porque fixou o SHA‑256 do arquivo Linux arm64 e começou a falhar. Sem canal privado de relato no repositório, o cliente abriu um problema público às 13h50 UTC, segundo a linha do tempo do OpenSourceMalware, e a OVHcloud removeu os arquivos trocados por volta das 14h21 UTC (16h21 em Paris). A versão v0.16.0 foi publicada às 17h16 UTC, sob a conta ovh-cds, com uma tag assinada.

O OpenSourceMalware relaciona a conta ao grupo de malware GlassWorm, que esconde código em caracteres Unicode invisíveis e busca sua próxima fase no campo memo de transações de carteira Solana. Quatro repositórios pessoais da conta foram forçadamente enviados em 5 e 6 de março com um commit modificado que adicionou um carregador desse tipo, descobriram os pesquisadores.

A carteira usada pelo carregador corresponde à campanha ForceMemo do GlassWorm, que forçou a inserção de malware em centenas de repositórios Python em março usando tokens de GitHub roubados. O Hacker News confirmou que o arquivo de carregamento ainda está em um desses repositórios, com o hash publicado pelos pesquisadores.

Se o mesmo agente atuou nos dois episódios "é nossa inferência", escreveram os pesquisadores. A conta compartilhada é a ligação, e nenhum artefato do binário de outubro foi associado ao GlassWorm, pois nenhuma cópia foi preservada.