Compromised GitHub Account Used to Poison Five OVHcloud CLI Releases With Infostealer

OVHcloud has disclosed that an attacker took control of a contributor's GitHub account and used it to swap out the downloadable archives attached to five already-published releases of the company's command-line interface tool. The malicious builds were designed to harvest secrets stored on the disk of any machine that executed them, and they remained available to the public for as long as 94 minutes.

What Happened

The tampering occurred on Monday, October 19. Rather than publishing new versions, the intruder replaced the existing release assets on five prior releases of the OVHcloud CLI — a distribution model that makes the swap especially dangerous, since anyone pulling a pinned or previously trusted version number could end up with the altered binary without any version indicator changing.

The window of exposure ran from 12:47 to 14:21 UTC, according to the cloud provider. That gives a maximum dwell time of just over an hour and a half during which downloads of the affected archives would have returned the attacker's payload instead of the legitimate tool.

Why Release-Asset Tampering Is a Serious Threat

Supply chain attacks that target build artifacts rather than source code are difficult for defenders to spot. The repository itself may look untouched, commit history may appear normal, and version tags remain identical — yet the file a user actually downloads and runs is different. Organizations that automate tool installation in CI/CD pipelines, container images, or developer onboarding scripts are particularly exposed, because a single compromised download can propagate across many environments quickly.

In this case the payload was purpose-built for credential theft. According to OVHcloud, the substituted files were a build engineered to steal secrets present on the disk of the machine running them. Developer workstations and build runners are high-value targets precisely because they tend to hold cloud API keys, SSH private keys, tokens, environment files, and configuration data for production infrastructure.

The Account Compromise Angle

Because the attacker operated through a hijacked contributor account, the malicious uploads would have carried the appearance of legitimacy — the release assets were modified by an identity with write access to the project. This reinforces a recurring lesson from open-source and vendor tooling incidents: the security of a release depends not only on code review but on the integrity of every account holding publish permissions, and on the protections around those accounts such as strong multi-factor authentication, scoped tokens, and audit visibility into release-asset changes.

Recommended Response for Users

OVHcloud customers and developers who use the CLI should treat any download of the affected releases during the exposure window as potentially compromised. Practical steps include:

  • Rotate credentials. Any secrets that were present on a machine where an affected archive was executed should be considered exposed. This includes cloud API keys, personal access tokens, SSH keys, database credentials, and contents of environment or configuration files.
  • Check for execution. Review endpoint telemetry, shell history, and CI/CD logs to determine whether the CLI was downloaded and run between 12:47 and 14:21 UTC on October 19.
  • Verify integrity going forward. Where the project publishes checksums or signatures, validate them before execution, and avoid pulling release assets from caches that may have captured the tampered files.
  • Hunt for follow-on activity. Credential theft is often a precursor to cloud resource abuse, so review cloud audit logs for anomalous API calls, new IAM principals, or unexpected resource creation originating from affected identities.

The Bigger Picture

This incident fits a broader pattern of attackers preferring the path of least resistance into trusted software distribution channels — compromised maintainer accounts, stolen publish tokens, and tampered release artifacts — over exploiting vulnerabilities in the software itself. The short exposure window is a mitigating factor, but it does not eliminate risk: automated pipelines can pull and execute a poisoned artifact within seconds of publication, and stolen secrets can be monetized long after the malicious files are removed.

Organizations should use this as a prompt to inventory which third-party CLIs and tools run inside their environments, confirm how those tools are fetched and verified, and tighten monitoring around the credentials those machines can reach.

Source

Original reporting: The Hacker News — Hackers Hijack Five OVHcloud CLI Releases to Distribute Secret-Stealing Malware