Hijacked OVHcloud developer account pushed secret-stealing CLI releases

A compromised OVHcloud developer GitHub account was used to replace release binaries of the company's command-line tool with malicious builds designed to harvest secrets from users' disks. OVHcloud's advisory, tracked as GHSA-862f-55f5-vmvw and rated High, states that the tampered archives were downloadable between 12:47 and 14:21 UTC on 19 October 2026, and instructs anyone who installed versions v0.11.0 through v0.15.0 during that window to regard every secret accessible from the affected machine as compromised.

How the attack unfolded

According to the advisory, the attacker used the hijacked account to swap the archives attached to five already-published releases. Source code, the build chain and other repositories were untouched — and that is the key detail: The Hacker News reports the malicious files were a straightforward Go build of a later commit, uploaded directly over the existing assets, so the release workflow never ran and CI checks were bypassed entirely.

The tampering was caught by a downstream user rather than by OVHcloud. Their CI pipeline had pinned the SHA-256 of the Linux arm64 tarball; when the pin began to fail, they opened an issue on the repository at roughly 13:50 UTC. A maintainer confirmed the malicious binaries were deleted at 14:21 UTC, and v0.16.0 followed as an immutable release carrying a signed tag.

Who is affected

The advisory lists the affected platforms as macOS on arm64 and x86_64, Linux on arm64 and x86_64, and Windows x86_64. Per OpenSourceMalware, the Linux i386, Windows i386, Windows arm64 and WASM builds were left alone. Versions v0.10.0 and earlier, and v0.16.0 and later, are considered clean.

The Hacker News identifies the exposed install routes: the official install script, which performs no hash check; manual downloads from the five release pages; CI jobs fetching without a pinned digest; and the CLI's own upgrade command moving from v0.12.0 to v0.14.0 on macOS and Linux. It considers Homebrew, go install, source builds and the Docker image safe, noting that the Homebrew cask pinned the original SHA-256. OpenSourceMalware disagrees and lists the cask as exposed; OVHcloud's advisory does not mention Homebrew. The consistent pattern: routes that verified a checksum stayed safe, routes that blindly trusted the release URL did not.

Press accounts also diverge on timing. BleepingComputer reports the malicious release appearing at 14:47 and blocked at 16:21 with no timezone stated; those are Paris local times. The advisory's UTC window of 12:47 to 14:21 is the authoritative one.

What affected users should do

OVHcloud's guidance, in order: hash the binary — without executing it — against the MD5 values published in the advisory, or check the temp directory for a folder named envchecker- followed by random digits, a sign the malware ran. Then rotate cloud, SSH, Git, Docker, Kubernetes and AI tooling credentials from a different machine, delete the binary, and install v0.16.0. OpenSourceMalware's checklist adds package-manager tokens and .env files, and BleepingComputer quotes OVHcloud's CEO urging affected users to change every secret stored on the machine. Any CI pipeline that fetched the CLI during the window without a pinned hash executed the swapped build on a runner holding deploy credentials, and should be audited as well.

Why it worked

GitHub releases are mutable unless a repository opts out: anyone with write access can delete an attached file and upload another under the same name, while the tag, the source archive and the release date all stay unchanged. BleepingComputer reports that OVHcloud's CEO attributed the incident to the release-immutability option being disabled, which let a sufficiently privileged account alter existing releases directly. OpenSourceMalware catalogues further weaknesses: releases published under personal accounts, a peripheral contributor holding release-asset write permission, an install script that skips checksum verification, no signing or provenance before v0.16.0, and no private channel for vulnerability reports, which forced disclosure through a public issue. The bundled checksums file offered no protection because it was among the files replaced on each release.

A tentative GlassWorm link

OpenSourceMalware connects the hijacked account to the GlassWorm malware family through a Solana wallet that appears in public indicator lists, but the researchers themselves describe the connection to the October swap as inference: no binary from the incident has been tied to GlassWorm, because none was preserved. Treat the attribution as provisional.

Why it matters

The episode is a clean demonstration that hardened pipelines are worthless when the artifact store behind them can be quietly rewritten. GitHub's release immutability setting — under Settings, Releases — locks a published release's assets and tag with a single checkbox, but it only protects releases published after it is enabled. For users, the practical defence is pinning hashes in CI and verifying downloads independently, since a checksum stored inside the same mutable release certifies nothing. And when compromise is suspected, credential rotation has to come before cleanup: installing a clean version does nothing about secrets already copied.