OVHcloud says a compromised developer GitHub account was used to replace official release binaries for its OVHcloud CLI with secret-stealing malware on Oct. 19, 2026.
The affected tool is a command-line utility used by developers and administrators to manage OVHcloud services from a terminal, including in automation workflows. OVHcloud’s GitHub security advisory rates the incident as high severity and lists no known CVE.
According to OVHcloud’s advisory, malicious binaries replaced existing release assets between 14:47 and 16:21 UTC+2 on Oct. 19. The company listed the malware availability window as 1h33 and said download statistics showed approximately 250 downloads.
The affected release assets were for v0.11.0 through v0.15.0. OVHcloud says users who downloaded those versions before the Oct. 19 window are unaffected. Versions v0.10.0 and earlier are listed as unaffected, and v0.16.0 was published as the replacement release.
The public GitHub issue that first flagged the problem initially identified replaced assets in v0.13.0, v0.14.0 and v0.15.0. OVHcloud’s later advisory expanded the affected range to include v0.11.0 and v0.12.0 as well.
The issue was spotted after a downstream customer’s CI job failed because it pinned the SHA-256 hash of an OVHcloud CLI release archive. The reporter noted that a replacement binary did not match the original release tag and appeared to be a local Go build with uncommitted changes.
Who was affected
OVHcloud says affected users are those who downloaded or updated the CLI during the Oct. 19 window and ran it on a computer. The advisory covers release artifacts for macOS on Arm and x86_64, Linux on Arm and x86_64, and Windows x86_64.
OpenSourceMalware identified the official install script, direct GitHub Releases downloads, and CI jobs or Dockerfiles fetching release archives as exposure paths. Its report also listed Homebrew, but the OVHcloud Homebrew cask pinned the original SHA-256 hashes, so standard Homebrew installations or upgrades would have rejected the tampered archives. The same report said users who built from source, used Go install, pulled the official Docker image, or installed before the affected window without updating during it were not affected.
The download count does not automatically equal confirmed infections. OVHcloud’s own impact test depends on whether the compromised binary was downloaded or updated during the affected period and then executed.
What the malware tried to collect
OVHcloud described the malicious binaries as the original CLI recompiled with malicious Go code embedded in it. The advisory says the malware was designed to collect secrets and files from the affected machine.
The targeted resources listed by OVHcloud include developer-tool databases and histories tied to VS Code, Cursor, Continue, Sourcegraph Cody, OpenCode, Hermes and Claude-related paths. The advisory also lists AWS, Google Cloud, Azure, Docker, Kubernetes, npm, DigitalOcean, SSH, Terraform, .netrc and global Git configuration files.
OVHcloud says the malware created a temporary working folder using an envchecker- name pattern, copied targeted files into it, prepared an archive and attempted exfiltration. The advisory also says that folder may remain on an affected system and can be used as one indicator when checking exposure.
For suspected exposure, OVHcloud’s guidance is direct: change or deactivate relevant secrets as soon as possible, delete the compromised binaries, and update or reinstall the CLI with v0.16.0.
The weak point was release-asset control
OVHcloud says source code and the build chain were not affected. The attack relied on replacing existing GitHub release assets.
OVHcloud says the main issue was that the GitHub repository was not configured to enforce release immutability. Without that protection, a sufficiently privileged account was able to alter already-published release files. The company says it corrected the configuration immediately and applied the same protection across repositories.
GitHub’s documentation says immutable releases lock release assets and their associated Git tag after publication, preventing release files from being modified or deleted. GitHub also says immutable releases automatically generate a release attestation that consumers can use to verify that artifacts match the published release.
The public record shows why that distinction matters. A checksum file stored beside a release artifact can be replaced along with the artifact if the attacker controls release assets. Independent hash pinning, verifiable release attestations and immutable release settings can help detect or prevent altered downloads. A signed Git tag authenticates the tag, but not the separate binary attached to a release.
Glassworm-linked indicators, but careful attribution
OVHcloud traced the root cause to a developer’s GitHub account. The advisory says the compromise began months earlier after the developer installed color-picker-universal 2.8.91 on a personal MacBook on Oct. 20, 2025. OVHcloud says the attacker later used stolen keys to replace OVHcloud CLI release binaries and that the developer’s OVHcloud laptop had not been compromised as far as the company knew at the time of the advisory.
The advisory says a Solana wallet associated with the earlier account compromise is known as a Glassworm indicator, citing prior reporting on the campaign. It also says several personal repositories tied to the account were compromised in March 2026.
That does not prove that the same actor carried out the October release swap. OpenSourceMalware described the link between the earlier account compromise and the Oct. 19 asset replacement as an inference, and SecurityWeek reported the same caution.
What this means for teams that use third-party CLI tools
The incident is a useful reminder that developer machines often hold more sensitive material than ordinary endpoints. A cloud CLI may sit near API keys, SSH keys, Kubernetes configuration, package registry tokens, Terraform credentials and source-control settings. If a trusted CLI becomes a delivery vehicle for malware, the exposure can move far beyond one vendor account.
For operators, the incident supports four practical controls:
Keep independent artifact verification. Hashes pinned in CI or stored outside the release page can catch a replaced binary even when the release page itself looks normal.
Prefer signed, immutable and attested releases. These controls do not remove every supply-chain risk, but they make silent asset replacement harder.
Limit who can change release artifacts. A developer account with enough rights to alter downloads can become a distribution risk even if the build system is untouched.
Treat developer CLIs as high-trust software. If a compromised tool ran on a workstation, stored secrets and local configuration files should be reviewed as exposure candidates, not just the tool’s own credentials.
OVHcloud says it suspended the compromised developer account from its GitHub organization, reviewed accounts with write access, reviewed repository logs, deleted the malicious assets and published v0.16.0 as a healthy release. The company also said it would review build and publication pipelines, signing practices, release immutability and GitHub account governance.
Get new small business insights by email
Practical ideas and useful articles to help you make better business decisions.
Tech Help Canada Staff researches, writes, and reviews practical content for business owners and professionals. Our coverage spans business, marketing, SEO, technology, and the tools and systems people use to grow and operate online. We focus on clear, useful information backed by research, hands-on experience, and editorial review. Learn more about our team and editorial standards. Need help with something? Contact Us
