A CLI da OVHcloud foi alvo de um ataque à cadeia de suprimentos de software que comprometeu arquivos de versões oficiais distribuídas pelo GitHub. Cibercriminosos conseguiram substituir binários legítimos da ferramenta por versões maliciosas capazes de roubar informações sensíveis, incluindo credenciais e segredos utilizados em ambientes de desenvolvimento e infraestrutura em nuvem. O incidente reforça um problema crítico para administradores de sistemas Linux e equipes de DevOps: até mesmo ferramentas baixadas de repositórios oficiais podem representar um risco quando o processo de distribuição é comprometido.
O ataque atingiu cinco versões da ferramenta, da v0.11.0 à v0.15.0, durante uma janela de exposição de aproximadamente 94 minutos. O risco depende da forma como a CLI foi instalada, da versão utilizada e da origem dos arquivos executáveis. Downloads diretos, scripts automatizados e pipelines de integração contínua sem validação de integridade merecem atenção especial.
Neste artigo, você vai entender como o ataque aconteceu, quais instalações podem ter sido afetadas, como investigar possíveis sinais de comprometimento no Linux e no macOS e quais medidas adotar para proteger chaves de API, credenciais e outros segredos. A principal lição é que confiar apenas no nome de um projeto ou na origem aparente de um download não é suficiente para garantir a segurança de um binário.
Como ocorreu o ataque às releases da CLI da OVHcloud
O incidente envolveu a adulteração de arquivos binários compilados em Go, disponibilizados nas releases da CLI da OVHcloud no GitHub. Em vez de explorar necessariamente uma vulnerabilidade no código-fonte da ferramenta, os invasores comprometeram a etapa de distribuição, substituindo executáveis legítimos por versões preparadas para atividades maliciosas.
Segundo os detalhes do incidente apresentados no cenário descrito, o invasor obteve acesso à conta de um colaborador e utilizou esse acesso para modificar os artefatos publicados. As versões afetadas foram a v0.11.0, v0.12.0, v0.13.0, v0.14.0 e v0.15.0.
A exposição durou aproximadamente 94 minutos. Embora seja uma janela relativamente curta, isso não elimina o risco. Ferramentas de linha de comando são frequentemente instaladas por scripts, executadas em servidores e incorporadas a pipelines de CI/CD. Um arquivo malicioso baixado nesse intervalo pode continuar presente em uma máquina mesmo depois da restauração das releases legítimas.
O objetivo do malware era coletar informações sensíveis do ambiente comprometido. Dependendo das permissões disponíveis e dos dados acessíveis, isso pode incluir tokens, chaves de API, credenciais de serviços e segredos armazenados em arquivos de configuração.
Para equipes de infraestrutura, o problema vai além de uma instalação individual. Se um binário contaminado for utilizado em uma estação de trabalho com acesso a ambientes de produção, o incidente poderá ampliar o risco para serviços, contas e recursos hospedados na nuvem.
O papel da imutabilidade de releases no GitHub
O recurso de releases imutáveis do GitHub foi desenvolvido para impedir que determinados artefatos publicados sejam modificados silenciosamente após a publicação. Quando a imutabilidade está ativa e uma release atende aos requisitos do recurso, os arquivos associados não podem ser substituídos livremente, o que dificulta esse tipo de adulteração posterior.
No caso da CLI da OVHcloud, a ausência dessa proteção nas versões legadas permitiu que os arquivos fossem alterados sem a necessidade de publicar uma nova versão formal do código-fonte.
É importante entender a diferença entre o código de uma release e seus binários. Um repositório pode apresentar um histórico de commits aparentemente legítimo enquanto os executáveis distribuídos aos usuários foram substituídos. Por isso, a revisão do código-fonte, isoladamente, não comprova a integridade dos arquivos baixados.
A versão v0.16.0 foi indicada como a versão limpa disponibilizada após o incidente. Atualizar para ela é uma medida importante, mas não deve ser considerada suficiente para máquinas que executaram um binário suspeito. Nesses casos, também é necessário investigar a exposição de credenciais.
A possível conexão com o grupo GlassWorm
Pesquisadores de segurança apontaram possíveis vínculos entre os elementos observados no incidente e atividades anteriormente associadas ao GlassWorm, um nome relacionado a campanhas que exploram ecossistemas de desenvolvimento e distribuição de software.
Entre as técnicas relacionadas a investigações desse tipo estão o uso de caracteres Unicode invisíveis para ocultar conteúdo malicioso, a manipulação de contas e repositórios e o abuso de componentes legítimos para distribuir código comprometido. Referências a operações envolvendo Solana também apareceram em relatos sobre atividades anteriores atribuídas a esse ecossistema de ameaças.
Entretanto, uma semelhança técnica não comprova, por si só, a autoria de um ataque. A atribuição exige correlação entre evidências, infraestrutura, amostras de malware e outros indicadores. Para as equipes responsáveis pela resposta ao incidente, a prioridade deve ser identificar os artefatos contaminados e determinar quais informações poderiam ter sido expostas, independentemente de quem esteja por trás da operação.
Quem foi exposto ao ataque à CLI da OVHcloud e quem está seguro
O principal fator para determinar a exposição é saber quando, de onde e como o binário foi obtido. A presença de uma das versões afetadas no histórico de downloads não significa automaticamente que a máquina executou o malware, mas exige investigação.
A janela de risco ocorreu em 19 de outubro de 2026, entre 12h47 e 14h21 UTC, conforme os registros divulgados sobre o incidente. No horário de Brasília, isso corresponde a aproximadamente 9h47 a 11h21.
Os cenários de maior atenção são:
- Instalação pelo script oficial: quem executou curl -fsSL https://raw.githubusercontent.com/ovh/ovhcloud-cli/main/install.sh | sh durante a janela de exposição pode ter recebido um arquivo comprometido.
- Download manual: usuários que baixaram arquivos ZIP ou TAR.GZ das versões v0.11.0 a v0.15.0 precisam verificar a procedência dos binários e se eles chegaram a ser executados.
- Pipelines de CI/CD: rotinas que baixaram os arquivos das releases sem validar um hash SHA-256 previamente confiável podem ter incorporado o executável malicioso a imagens, agentes de compilação ou ambientes de implantação.
- Atualizações automatizadas: scripts que instalaram ou atualizaram a ferramenta sem uma versão e um digest fixos também devem ser auditados.
Os sistemas mais relevantes para a investigação incluem Linux x86-64, Linux ARM64, macOS x86-64, macOS ARM64 e Windows x86-64. Nem todas as arquiteturas e todos os formatos distribuídos foram afetados.
Quais instalações não foram afetadas?
De acordo com as informações disponíveis sobre o incidente, as seguintes situações não estão entre os caminhos de comprometimento identificados:
- Homebrew: o cask utiliza um hash estático para validar o arquivo esperado. Como a adulteração altera o conteúdo do binário, a verificação de integridade impede que um arquivo diferente seja aceito como se fosse o original, desde que a validação não tenha sido contornada.
- Compilação a partir do código-fonte: instalações feitas com go install github.com/ovh/ovhcloud-cli/cmd/ovhcloud@... obtêm o código do módulo, em vez de baixar diretamente os executáveis adulterados das releases.
- Imagem Docker oficial: o uso da imagem oficial não foi identificado como um dos caminhos atingidos pela substituição dos arquivos de release.
- Instalações antigas sem atualização durante o ataque: uma cópia legítima instalada antes da janela de exposição não foi contaminada apenas porque sua versão estava entre as cinco listadas. O risco muda se o arquivo tiver sido substituído posteriormente.
Essas distinções não dispensam a verificação de procedência. Uma instalação inicialmente segura pode ter sido substituída por um script interno, por uma etapa de atualização ou por um processo de implantação que buscou os arquivos comprometidos.
Como verificar se a máquina foi infectada e aplicar medidas de mitigação
A resposta deve combinar auditoria do binário, investigação do ambiente e rotação de credenciais. Remover o executável é necessário, mas não resolve o problema se o malware já tiver acessado segredos armazenados no disco.
1. Identifique a versão e os metadados do executável
No Linux ou macOS, localize o binário utilizado:
command -v ovhcloudO resultado indica o caminho do executável encontrado pelo shell. Caso existam instalações em diretórios diferentes, verifique também:
type -a ovhcloudEm seguida, consulte os metadados de compilação com a ferramenta do Go:
go version -m "$(command -v ovhcloud)"O comando apresenta informações como o caminho do módulo, a versão declarada e os dados de compilação registrados no executável.
Nos binários suspeitos descritos no incidente, um dos sinais relevantes é a presença de metadados associados ao commit 5ead8ef9b43d, além de indícios de árvore de trabalho modificada, frequentemente identificados pelo marcador +dirty. A ausência das informações de versão normalmente injetadas no processo de compilação também merece investigação.
Compare esses dados com a versão esperada e com o código correspondente à release oficial. Um número de versão aparentemente correto não comprova autenticidade: os metadados ajudam na triagem, mas podem ser manipulados por quem controla a compilação.
Se o arquivo suspeito já tiver sido removido, consulte registros de implantação, caches de CI/CD, imagens de contêiner e backups para descobrir qual binário foi utilizado.
2. Interrompa o uso e preserve as evidências
Se houver suspeita de comprometimento, interrompa a execução da CLI e impeça que scripts de automação continuem utilizando o arquivo. Em servidores de produção, siga o procedimento de resposta a incidentes da organização antes de realizar alterações que possam destruir evidências.
Registre o caminho do executável, a versão, a data de instalação e os logs disponíveis. Procure também por cópias em diretórios de ferramentas, caches de downloads, agentes de compilação e imagens utilizadas em implantações.
A análise deve considerar se o binário foi apenas baixado ou se chegou a ser executado. A execução amplia significativamente a preocupação, sobretudo em máquinas com acesso a credenciais de nuvem.
3. Remova o binário comprometido e instale uma versão limpa
Depois de preservar as evidências necessárias, remova a cópia suspeita e instale a v0.16.0 ou uma versão posterior confirmada como segura. Não reutilize um arquivo antigo apenas porque ele ainda está disponível em um cache local.
Prefira uma distribuição com integridade verificável e releases imutáveis. Evite executar novamente um script de instalação sem conferir como ele seleciona a versão, de onde baixa os arquivos e se valida a integridade do conteúdo.
4. Troque as chaves de API e os segredos acessíveis
Esta é uma das medidas mais importantes. Se a CLI comprometida foi executada, considere expostos os segredos que estavam acessíveis à conta e ao processo naquele momento.
A partir de um sistema limpo e confiável, revogue e gere novamente as chaves de API da OVHcloud, os tokens de acesso e outras credenciais potencialmente disponíveis no disco. Avalie também arquivos .env, configurações de provedores de nuvem, credenciais de SSH, tokens de CI/CD e segredos de repositórios.
Não basta alterar apenas a senha da conta principal. Credenciais secundárias podem manter acesso persistente a serviços, máquinas virtuais, armazenamento e pipelines. Examine os registros de autenticação e atividade da nuvem em busca de operações desconhecidas.
5. Verifique a integridade dos arquivos e dos pipelines
A ferramenta gh do GitHub CLI disponibiliza o comando release verify-asset, que pode ser utilizado para verificar a assinatura de um artefato quando existe uma assinatura válida associada à release.
Um exemplo de uso é:
gh release verify-asset v0.16.0 \ ./ovhcloud-cli.tar.gz \ --repo ovh/ovhcloud-cliO arquivo local deve corresponder a um artefato assinado e verificável da release indicada. A verificação não deve ser interpretada como uma garantia universal para qualquer arquivo baixado: ela depende da existência de uma assinatura válida e dos mecanismos de verificação aplicáveis àquele artefato.
Também é fundamental entender que um hash publicado junto com um arquivo comprometido não garante autenticidade. Se o invasor puder substituir tanto o binário quanto o arquivo de checksums, os dois poderão concordar entre si e continuar maliciosos. Para uma validação forte, compare o hash com um valor obtido de uma fonte confiável e independente ou utilize assinaturas verificadas criptograficamente.
Nos pipelines de CI/CD, fixe a versão e o digest esperado, interrompa a implantação quando a validação falhar e evite downloads dinâmicos de artefatos que não tenham uma origem autenticada.
O que o ataque à CLI da OVHcloud ensina sobre segurança em ferramentas de linha de comando
O incidente demonstra que a segurança de uma ferramenta não depende apenas da qualidade do código-fonte. A cadeia de distribuição também precisa ser protegida, desde as contas dos colaboradores até os arquivos disponibilizados para download.
A adulteração das releases da CLI da OVHcloud não exigiu necessariamente uma alteração no código associado às versões publicadas. O comprometimento de uma conta com permissões suficientes permitiu modificar os artefatos de distribuição, criando uma diferença entre o código revisável e o executável recebido pelos usuários.
Para projetos de código aberto, esse cenário reforça a importância de habilitar releases imutáveis, proteger contas de mantenedores com autenticação multifator resistente a phishing e limitar as permissões usadas para publicar versões. A automação de builds também deve separar as credenciais de publicação das atividades comuns de desenvolvimento.
Nas equipes de DevOps, a principal recomendação é abandonar a confiança implícita em downloads realizados durante a execução de scripts. Sempre que possível, utilize versões fixas, hashes previamente confiáveis, assinaturas verificáveis e registros que permitam rastrear a origem de cada artefato.
O mesmo cuidado vale para outras ferramentas de infraestrutura. Clientes de nuvem, utilitários de Kubernetes, ferramentas de automação e dependências usadas na compilação podem ter acesso privilegiado a ambientes críticos. Um único binário comprometido pode transformar uma estação de trabalho de desenvolvimento em um ponto de exposição de credenciais corporativas.
Se você utiliza a CLI da OVHcloud, verifique a versão instalada, investigue downloads realizados durante a janela do incidente e substitua imediatamente as credenciais que possam ter sido expostas. Compartilhe este alerta com as equipes de infraestrutura, desenvolvimento e segurança responsáveis pelos seus ambientes Linux e de nuvem.