Your vote:

Date create:
21 October 2026
Created user name:

OVHcloud says compromised CLI releases briefly distributed secret-stealing malware

OVHcloud has disclosed a software supply-chain incident affecting its command-line tool after an attacker used a contributor's compromised GitHub account to replace download archives on five existing releases. According to the company, the malicious files were available for up to 94 minutes on 19 October and were designed to steal secrets stored on disk from any machine that executed them.

What happened

According to the reported disclosure, an attacker gained access to a contributor's GitHub account and used it to modify the download archives attached to five existing OVHcloud CLI releases. OVHcloud said the altered files were malicious builds intended to collect secrets from the local system.

The compromised archives were reportedly available on GitHub from 12:47 to 14:21 UTC on 19 October. Based on the information available, this was not described as a compromise of all OVHcloud services, but as a targeted attack on distributed CLI release files.

Because the affected software is a command-line tool, the main risk is to organisations or developers who downloaded and executed one of the altered release archives during the exposure window.

Why it matters for European businesses

This is a notable example of a software supply-chain attack: instead of directly breaching every target company, attackers tamper with a trusted tool used by developers, administrators or automation systems. For businesses, that can create a path to cloud credentials, API tokens, configuration secrets and other sensitive information stored on workstations or servers.

Many European SMEs and digital teams rely on command-line tools in routine operations such as infrastructure management, CI/CD workflows, backups, deployment scripts and cloud administration. If a compromised binary is executed in those environments, the impact can go beyond a single device and potentially affect cloud accounts, production systems or customer data depending on what secrets are accessible.

The incident also highlights a broader operational risk: businesses often trust official release pages on code platforms such as GitHub without independently verifying file integrity or restricting where administrative tools can run.

Who may be affected

  • IT and DevOps teams using the OVHcloud CLI on laptops, servers or administrative jump hosts.
  • Companies running automation that download CLI tools as part of scripts, containers or CI/CD jobs.
  • E-commerce and digital businesses hosting workloads or infrastructure connected to OVHcloud environments.
  • Agencies and managed service providers administering multiple client environments from shared operator machines.

Risk is highest for organisations that downloaded and ran one of the affected releases during the reported time window. Systems with locally stored tokens, SSH keys, API credentials or cloud configuration secrets may require particular attention.

What companies should consider

  • Identify exposure quickly. Check whether any team member, server or pipeline downloaded OVHcloud CLI release archives during the reported exposure period on 19 October.
  • Treat executed binaries as potentially credential-compromising. If an affected archive may have been run, review what secrets were stored on that machine, including API keys, access tokens, SSH material and cloud credentials.
  • Rotate sensitive credentials where necessary. Prioritise credentials that could provide access to production systems, cloud infrastructure, storage, backups or customer data.
  • Review logs and account activity. Look for unusual authentication events, API calls, infrastructure changes or access from unexpected locations following any possible execution.
  • Strengthen software verification controls. Consider checksum verification, signed releases, approved internal package mirrors or restricted installation methods for admin tools used in production workflows.
  • Limit secret exposure on endpoints. Reduce the number of long-lived credentials stored on developer machines and automation hosts, and use least-privilege access where possible.
  • Reassess GitHub and supplier trust assumptions. This incident shows that official repositories can still be abused if contributor accounts are compromised.

For European businesses, the practical lesson is not limited to OVHcloud. Any organisation using third-party developer tooling should review how it validates downloads, stores secrets and responds to supplier-side software tampering incidents.