O CLI oficial da OVHcloud esteve adulterado durante hora e meia

Entre as 14h47 e as 16h21 de 19 de Outubro, o repositório oficial do ovhcloud-cli esteve a servir cinco versões adulteradas. O ficheiro que o utilizador instalava já não era a ferramenta da OVHcloud: era o mesmo programa recompilado com um ladrão de segredos dentro. A empresa deu conhecimento do incidente na terça-feira e considera o caso resolvido.

A ferramenta, a command line interface (interface de linha de comandos), é a forma de gerir a conta da OVHcloud a partir do terminal, usada por administradores de sistemas e por programadores que automatizam tarefas. É por isso um alvo: quem a instala entrega ao seu computador o acesso à própria conta.

Uma janela de hora e meia

As versões v0.11.0, v0.12.0, v0.13.0, v0.14.0 e v0.15.0 foram substituídas às 14h47. Às 15h50, um cliente da OVHcloud reportou a situação num aviso do próprio repositório. A investigação começou sete minutos depois e, às 16h20, a empresa começou a varrer todos os seus repositórios no GitHub. Às 16h21, os binários adulterados foram removidos.

A OVHcloud calcula uma disponibilidade de 1h33 para os ficheiros adulterados e fala em cerca de 250 transferências. O anúncio público saiu às 18h52 e, às 19h16, a empresa publicou a versão v0.16.0, já com etiqueta assinada, para forçar a atualização de quem ainda usasse uma versão antiga.

A porta de entrada não foi a infraestrutura da empresa: foi uma conta individual de programador no GitHub, comprometida meses antes. Segundo a OVHcloud, a imutabilidade das versões publicadas estava desligada, o que permitia a uma conta com permissão substituir ficheiros já publicados sem passar pelos testes automáticos de integração contínua.

A cronologia segundo o post-mortem da OVHcloud, com o que o binário procurava no disco. A infografia é do Portugal Binário e não reproduz o repositório nem os ecrãs do atacante.

Crédito: Infografia do Portugal Binário, com dados do post-mortem da OVHcloud (19 out. 2026)

O que o binário levava do computador

A lista de alvos é mais larga do que a do malware habitual. O programa procurava chaves SSH, o ficheiro .netrc com as credenciais de serviços, a configuração global do Git, as credenciais da AWS, da Google Cloud e da Azure, e ainda a configuração do Docker, do Kubernetes e do Terraform.

E, em casa de quem usa ferramentas de inteligência artificial, o mesmo software procurava as bases de dados do VS Code, do Cursor, da extensão Continue e do Sourcegraph Cody, os ficheiros do Claude e do OpenCode e as sessões do Hermes, o agente que corre em segundo plano. É a lista do que um programador tem nas suas pastas.

Segundo a OVHcloud, o programa não apagava o rasto: em cada execução copiava os ficheiros recolhidos para uma pasta temporária com um nome começado por envchecker seguido de algarismos, que nunca voltava a eliminar, e enviava o conjunto para um endereço IP próprio e para uma chamada na rede Solana.

Pasta deixada pelo programa (verificar e apagar):
  /tmp/envchecker-<9 ou 10 algarismos>

Endereço de exfiltração indicado pela OVHcloud:
  45.32.148.174:443

Carteira da rede Solana usada nas chamadas:
  BHaDaVbdCYFNaKZGn7yLXFneWoJHZgLiBYkHxVrjyALF

Hashes MD5 dos ficheiros adulterados: no apêndice do post-mortem
Versões limpas: v0.10.0 e anteriores  |  v0.16.0 e posteriores

Como se chega a uma conta de programador

A resposta está um ano antes do incidente. Em 20 de Outubro de 2025, o programador instalou no portátil pessoal a extensão color-picker-universal 2.8.91 do Visual Studio Code. A OVHcloud diz que a extensão registou um serviço permanente em segundo plano e que a carteira de Solana usada dentro dela é conhecida como pertencente ao grupo GlassWorm.

Em Março de 2026, vários repositórios pessoais da mesma conta foram comprometidos, e as versões da CLI foram substituídas com as chaves roubadas, não a partir do portátil. A OpenSourceMalware encontrou no histórico uma reescrita automática a 5 de Março e um carregador escondido, um ficheiro preinstall.js, que descodifica uma segunda fase depositada numa mensagem da rede Solana.

É a mesma família que, desde o final de 2025, tem atacado registos de extensões e de pacotes de código, incluindo o VS Code, o OpenVSX, o GitHub e o npm. O que traz o caso da OVHcloud para a actualidade é ter chegado ao canal oficial de distribuição de um fornecedor de nuvem europeu.

O que fazer se instalaste a CLI nesse intervalo

• Trocar ou revogar todos os segredos guardados na máquina: chaves SSH, tokens de API, credenciais da AWS, da Google Cloud e da Azure, do Docker, do Kubernetes e do Terraform.
• Verificar a pasta temporária do sistema: se existir uma pasta envchecker-999999999, o programa foi executado.
• Comparar o hash MD5 do ficheiro instalado com a lista do post-mortem e apagar os ficheiros adulterados.
• Reinstalar a ferramenta a partir da versão v0.16.0 ou posterior, já com etiqueta assinada.

Fizemos o mesmo teste na máquina onde escrevemos este artigo: a ferramenta da OVHcloud nunca foi instalada, não há executáveis com o nome ovh no caminho do sistema e não existe nenhuma pasta envchecker na pasta temporária. É o resultado que a empresa pede a quem não apanhou a janela.

O que a OVHcloud mudou

A empresa activou a imutabilidade das versões publicadas em toda a organização, publicou a v0.16.0 com etiqueta assinada e reviu as contas com acesso de escrita. Anuncia ainda a revisão de todos os pipelines de publicação, a assinatura sistemática de commits, a imutabilidade de todas as versões e a ligação das contas ao sistema central de identidade da empresa.

O fundador e administrador delegado da OVHcloud, Octave Klaba, escreveu que a qualidade do binário é má, «mas consegue ir até ao fim», e pediu a quem tivesse descarregado a versão afetada que limpe o sistema e que troque todos os segredos guardados no disco. A empresa dá o incidente como resolvido.

Ficam duas perguntas em aberto. A OpenSourceMalware não analisou o código malicioso entregue pela versão adulterada da CLI, e as 250 transferências são o que a empresa consegue contar: quantos binários chegaram a ser executados é desconhecido. O que fica claro é o padrão: o canal oficial de distribuição, e não o código, foi o ponto de falha.