An attacker hijacked a contributor’s GitHub account and swapped files on five OVHcloud CLI releases on October 19, 2026. The build was meant to retrieve secrets from the disk, according to OVHcloud.
At a Glance
- OVHcloud lists v0.11.0 through v0.15.0 as compromised and v0.10.0 as clean. The new v0.16.0 is a clean, immutable release, per OVHcloud’s maintainers.
- The swapped files were live for up to 94 minutes, from 12:47 to 14:21 UTC. Only people who installed or updated in that window on macOS, Linux x86_64 or arm64, or Windows x86_64, via a path that checks for no hash, were hit.
- Anyone affected should change every secret stored on the disk, according to Octave Klaba, OVHcloud’s founder and CEO. Updating the tool does not revoke a key that was already copied.
- The root cause was GitHub’s release immutability setting, which was disabled, per Klaba. OVHcloud has not said which files the binary reads, where it sends them, or how many copies were downloaded.
- The attack was likely part of a new GlassWorm operation, according to OpenSourceMalware, a community-driven threat intelligence platform.
Hijacked account rewrote five GitHub releases
On v0.15.0, the attacker replaced six files. One was checksums.txt, so the published hashes matched the new binaries. On GitHub’s growing platform, anyone with write access can delete a release’s files and upload new ones under the same names.
A customer’s CI job caught the swap. It pins the SHA-256 of the Linux arm64 archive and began failing. The customer raised it in a public GitHub issue, number 300. OVHcloud deleted the swapped files about half an hour later, and v0.16.0 followed at 17:16 UTC.
Klaba later explained the gap. With the setting off, a sufficiently privileged account could modify existing releases without passing CI/CD checks. The setting protects only releases created after it is enabled.
AWS CodeBuild supply chain risk analysis describes another route to the same outcome. CodeBreach, a critical bug in AWS CodeBuild, could have enabled full takeover of AWS GitHub repositories.
Klaba described the build bluntly in French; translated, he wrote: The quality of the binary is poor but it can go all the way. He said the entire set of CI/CD pipelines were not impacted.
GlassWorm has run campaigns since late 2025 across the VSCode, OpenVSX, GitHub, and npm ecosystems. The researchers did not analyze the malicious payload. Nothing from the October binary has been tied to GlassWorm, because no copy of it was preserved.
🚨 Attackers hijacked five OVHcloud CLI releases on GitHub, replacing legitimate downloads with malware designed to steal secrets from infected machines. The malicious files were available for up to 94 minutes on October 19. Users who downloaded or updated affected builds during that window should rotate exposed secrets. Read more: https://t.co/fGBwxkGRqJ
— The Hacker News (@TheHackersNews) October 20, 2026
Install route decided who was exposed
The official install script downloads the latest release archive and installs it, and has never checked a hash.
Homebrew installs were not affected. The cask in force during the window pinned the original SHA-256 of each archive, so Homebrew refuses a download whose hash does not match. Source builds and Docker images remained unaffected, per OpenSourceMalware.
The CLI’s documentation says the CLI keeps OVHcloud API credentials in ~/.ovh.conf and reads them from environment variables. The advice covers everything else on the disk. OpenSourceMalware adds that rotation should happen from a different machine.
Afterward, install v0.16.0 and check a downloaded archive with gh release verify-asset v0.16.0 FILE, as GitHub documents. Rotating first helps reduce the risk that a copied key gets reused.
Of the five releases, public documentation of the swap covers only three of them, 0.13.0 through 0.15.0. For 0.11.0 and 0.12.0, the swap rests on OVHcloud’s word.
The cleanup now falls to the security teams running those machines: a secret rotation on every affected host.
Only one control fired, and it sat outside the repository: a hash a single customer had pinned for themselves. The publisher’s own checksum file was swapped to match, so it could not have raised the alarm. OVHcloud has promised a detailed postmortem in the coming days.
