Instalou a CLI da OVHcloud a 19 de outubro? Os seus segredos podem já não ser seus

Durante cerca de hora e meia, na tarde de 19 de outubro de 2026, quem descarregou a ferramenta oficial de linha de comandos (CLI) da OVHcloud a partir do GitHub pode ter instalado um programa feito para roubar segredos guardados no disco. O fornecedor francês de cloud e alojamento confirmou que um atacante usou a conta GitHub de um dos programadores do projeto para substituir os binários de cinco versões já publicadas, da v0.11.0 à v0.15.0. A empresa bloqueou os ficheiros maliciosos, publicou uma versão limpa (v0.16.0) e corrigiu a configuração que tornou o ataque possível. Investigadores independentes associam a conta comprometida à campanha GlassWorm, mas a própria OVHcloud não faz essa atribuição.

O que aconteceu no repositório da OVHcloud

A CLI oficial da OVHcloud é uma ferramenta open source que permite gerir os serviços do fornecedor a partir do terminal ou de pipelines de CI/CD: servidores bare metal, Public Cloud, Kubernetes gerido, VPS, IAM e outros. Por isso, as máquinas onde corre guardam muitas vezes credenciais com poder real sobre infraestrutura em produção, como a application_key, a application_secret e a consumer_key da API.

O alerta foi dado pelo fundador da OVHcloud, Octave Klaba, na rede social X. Segundo Klaba, a versão comprometida ficou disponível às 14h47 (hora de Paris) e foi detetada e bloqueada às 16h21, depois de um cliente ter reportado o problema. Klaba descreveu o binário como sendo de má qualidade, mas avisou que podia cumprir o objetivo de recolher segredos do disco. A recomendação foi clara: quem descarregou a CLI nesse dia devia voltar a atualizá-la de imediato ou apagá-la e, se tivesse sido afetado, mudar todos os segredos guardados no disco.

A deteção não partiu da OVHcloud. De acordo com os investigadores da plataforma comunitária OpenSourceMalware, foi um utilizador externo que deu pelo problema: o seu pipeline de integração contínua fixava o hash SHA-256 original do ficheiro, a verificação automática falhou e o utilizador abriu um issue público no repositório.

Versões e plataformas afetadas

O incidente não tem identificador CVE, porque não se trata de uma vulnerabilidade no código. O aviso de segurança publicado no repositório (GHSA-862f-55f5-vmvw) classifica o caso com severidade elevada.

Sobre o Homebrew, as fontes não coincidem. A OpenSourceMalware inclui o comando brew install --cask ovh/tap/ovhcloud-cli entre os métodos expostos. Outras análises defendem que o cask fixava o hash original e teria recusado o ficheiro trocado. O aviso da OVHcloud não refere o Homebrew. Por precaução, quem instalou ou atualizou por esta via durante a janela do incidente deve agir como se tivesse sido afetado.

Uma definição desligada abriu a porta

Na análise posterior, Klaba garantiu que os pipelines de CI/CD, incluindo testes unitários, testes funcionais e deteção de CVE, não foram comprometidos. A causa foi outra: o repositório não tinha ativada a opção de imutabilidade das releases do GitHub. Assim, qualquer utilizador com as permissões certas podia alterar diretamente releases já publicadas, sem passar por nenhum controlo da CI/CD. A opção foi entretanto ativada e a empresa dá o incidente por encerrado.

A reconstrução técnica da OpenSourceMalware mostra como o ataque explorou essa falha. Os uploads foram feitos através da API normal do GitHub Releases, a partir da conta HassenBF, que pertence a um colaborador legítimo da OVHcloud com permissões de escrita. Não foi criada nenhuma tag e nenhum workflow do GitHub Actions foi executado. O binário malicioso foi compilado com go build numa estação de trabalho com alterações não submetidas e colocado sobre os ficheiros originais de releases existentes.

O atacante foi seletivo. Cada versão gerada pelo GoReleaser inclui nove arquivos de plataforma e um ficheiro checksums.txt, mas só os binários das plataformas mais usadas foram trocados. Na v0.15.0, o próprio checksums.txt foi alterado para que as somas de verificação publicadas batessem certo com os ficheiros maliciosos. Na prática, quem verificava a integridade com a lista do próprio repositório não teria detetado nada. Só quem tinha o hash original fixado do seu lado deu pela troca. Para os investigadores, a escolha das plataformas aponta para a recolha de credenciais em estações de programadores e equipas de operações.

Cronologia do incidente

A pista GlassWorm: o que está provado e o que não está

Segundo a OpenSourceMalware, a conta usada no ataque estava comprometida há cerca de sete meses. Em março de 2026, quatro repositórios pessoais do titular foram reescritos com force push e três passaram a incluir um ficheiro preinstall.js, que corre automaticamente durante o npm install. Esse loader descodifica uma segunda fase que consulta uma transação na blockchain Solana para saber onde está o payload seguinte, uma técnica conhecida como dead drop. A carteira usada é um indicador público da campanha GlassWorm e o método de reescrita coincide com a campanha ForceMemo.

A GlassWorm está ativa desde o final de 2025 e tem visado ecossistemas de programação como o VS Code, o OpenVSX, o GitHub e o npm. Mesmo assim, os investigadores dizem que a ligação entre o comprometimento de março e o ataque de outubro é uma inferência sua, e não um facto confirmado. Não há análise pública do payload de outubro, porque a OVHcloud apagou os ficheiros antes de alguém os conseguir arquivar. A empresa também não disse que ficheiros o binário lia, para onde os enviava, nem quantas pessoas o descarregaram.

Indicadores de comprometimento

O aviso GHSA-862f-55f5-vmvw no repositório da OVHcloud tem também os valores MD5 dos binários maliciosos de cada plataforma, que devem ser consultados para verificação local.

O que fazer se pode ter sido afetado

• Localize o binário ovhcloud e calcule o seu hash sem o executar. Compare-o com os indicadores do aviso oficial.
• Apague o binário e instale a v0.16.0. Com a CLI do GitHub, pode confirmar a integridade com gh release verify e gh release verify-asset.
• A partir de outra máquina, revogue e volte a gerar as chaves da API da OVHcloud e todos os outros segredos acessíveis no disco: chaves SSH, tokens do GitHub e de fornecedores de cloud, ficheiros .env, credenciais do Kubernetes.
• Reveja os registos de atividade da conta OVHcloud e de outros serviços à procura de acessos ou recursos criados sem autorização.
• Nos pipelines, fixe os hashes dos artefactos descarregados em vez de confiar apenas nas somas publicadas no repositório.
• Se mantém projetos no GitHub, ative a imutabilidade das releases (só se aplica às versões publicadas depois de ativada) e reveja quem tem permissões de escrita.

Porque é que isto importa em Portugal

A OVHcloud tem muitos clientes portugueses, de programadores independentes e PME a organizações maiores que alojam lá sítios, aplicações e infraestrutura de cloud. O caso mostra um risco que vai além das vulnerabilidades no código: uma ferramenta oficial, descarregada do sítio certo, pode vir adulterada quando a conta de um colaborador é comprometida e o processo de publicação deixa que artefactos já lançados sejam alterados sem controlo.

Para as entidades abrangidas pelo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a NIS2), a segurança da cadeia de abastecimento faz parte das medidas de gestão de risco exigidas. Isto inclui a verificação da integridade do software de terceiros e a gestão de credenciais privilegiadas. Um incidente com impacto significativo resultante do uso de uma ferramenta adulterada pode ter de ser notificado ao CNCS/CERT.PT. Se os segredos roubados derem acesso a sistemas com dados pessoais, há ainda obrigações ao abrigo do RGPD, incluindo a avaliação da necessidade de notificar a CNPD no prazo de 72 horas.

Perguntas frequentes

Que versões da CLI da OVHcloud estavam comprometidas?

As versões v0.11.0, v0.12.0, v0.13.0, v0.14.0 e v0.15.0 descarregadas do GitHub Releases entre as 12h47 e as 14h21 UTC de 19 de outubro de 2026. As versões v0.10.0 e v0.16.0 estão limpas.

Estou afetado se instalei com go install ou Docker?

Não. O código-fonte e as tags não foram alterados, por isso a instalação com go install ou a compilação a partir do código não foram afetadas. Segundo a OpenSourceMalware, a imagem Docker também não. Quanto ao Homebrew, as fontes divergem e o mais prudente é agir como se tivesse sido afetado.

O ataque foi feito pelo grupo GlassWorm?

Não está confirmado. A OpenSourceMalware encontrou na conta comprometida indicadores ligados à GlassWorm, mas considera que a ligação ao ataque de outubro é uma inferência. A OVHcloud não atribuiu o incidente a nenhum grupo.

O que devo fazer se executei uma versão afetada?

Apague o binário, instale a v0.16.0 e, a partir de outra máquina, revogue e volte a gerar todos os segredos acessíveis nesse computador: chaves de API da OVHcloud, chaves SSH, tokens e palavras-passe. Depois, reveja os registos de atividade das contas.

Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela OVHcloud, pela OpenSourceMalware, pelo BleepingComputer e pela Help Net Security.