Hijacked GitHub account backdoors five OVHcloud CLI releases for 94 minutes

OVHcloud's command line interface is a small but important piece of plumbing for developers who manage cloud resources from a terminal. On October 19, 2026, that plumbing became a supply chain risk when an attacker used a compromised developer GitHub account to replace download archives on five existing releases of the tool. The affected versions were v0.11.0 through v0.15.0, according to OVHcloud, and the malicious files were built to pull secrets from the disk of any machine that ran them. The company's chief executive, Octave Klaba, described the incident publicly as a supply chain attack after a customer reported it.

The window was short but not trivial. The Hacker News reported on October 20 that the swapped archives were live on GitHub for up to 94 minutes, from 12:47 to 14:21 UTC. The Stack reported on October 19 that Klaba said a malicious version released by the hacker was spotted and blocked in 94 minutes. BleepingComputer reported on October 20 that Klaba said the compromised release appeared at 14:47 and was detected and blocked at 16:21. The reports differ on clock time, but both describe a 94 minute exposure.

OVHcloud did not describe a compromise of its source code, release tags or build pipeline. Instead, the attacker uploaded a plain go build of a later commit straight onto releases that had been published between April and September. On v0.15.0, six files were replaced: the macOS x86_64 and arm64 archives, the Linux x86_64 and arm64 archives, the Windows x86_64 archive, and checksums.txt. Replacing the checksum file meant the published hashes matched the new binaries.

The incident quickly drew attention because it combined a familiar weakness, a stolen developer account, with a less familiar detail: GitHub release immutability was disabled. That setting lets a sufficiently privileged account modify existing releases without passing CI/CD checks, Klaba said in a later update. OVHcloud has since enabled release immutability and considers the incident resolved, but the company urged anyone who downloaded a compromised package to clean the system and revoke all secrets. BleepingComputer reported on October 20 that the CI/CD pipelines with unit and functional tests and CVE detection were not impacted.

Key Facts

OVHcloud lists v0.11.0 through v0.15.0 as compromised and v0.10.0 as clean. Those five releases were published between April 14 and September 16. OVHcloud published a clean v0.16.0 that evening as an immutable release. The Hacker News reported on October 20 that the source code, the release tag and the company's build pipeline were not touched, and that the bad build was a plain go build of a later commit. The archives reached only people who installed or updated the OVHcloud CLI during the 94 minute window, through a path that checks for no hash, on macOS, Linux x86_64 or arm64, or Windows x86_64.

The customer who caught the swap used go version -m to read the new v0.15.0 Linux arm64 binary without running it. The binary reported a pseudo-version, v0.15.1-0.20261013083505-5ead8ef9b43d+dirty, built from commit 5ead8ef rather than the tagged 760fd72. The customer also noted that the account making the changes, HassenBF, was not a public member of the ovh org and did not appear among the repository's contributors, The Stack reported on October 19. The customer asked for release assets to be treated as immutable or new versions published instead, and said there was no private vulnerability reporting channel enabled on the repository.

Homebrew users were protected because the cask pinned the original SHA-256. go install, source builds and the Docker image were unaffected; the Docker image was last pushed on September 21, The Hacker News reported on October 20. The published SHA-256 of the swapped Linux arm64 archive was 3833daffcaaaab27e4e0e0833240ffcb1df8df648f4ec0bc4a75c176e28933cb. The original hash was 5c2beb56e6d83a4b426565a1557791ef759316abcc4effb38dd627c90aeb80e0. OVHcloud said the quality of the binary was poor but it could go all the way.

BleepingComputer reported on October 20 that researchers said the account had been compromised for more than half a year, with a scripted history rewrite on March 5, 2026. The same report said the attack was likely part of a new GlassWorm operation, a campaign active since late 2025 that has hit the VSCode, OpenVSX, GitHub and npm ecosystems. A hidden preinstall.js loader decoded a second stage using a Solana memo dead drop. OVHcloud has not confirmed the GlassWorm attribution in the materials reviewed here.

Analysis

The most important control failure here was not the compromise of a developer account, painful as that is. It was that existing release assets could be changed in place. That turned a stolen login into a distribution channel for every user who fetched a binary during the 94 minute window. The Hacker News reported on October 20 that the attacker replaced archives on five existing releases, which is a different risk from publishing a new malicious version. A new version can be reviewed, pinned or held back; a swapped asset under a familiar version number can slip past users who trust the release line.

What this really means is that release immutability is not a minor setting for open source projects that ship installers. GitHub's release immutability setting was disabled, and Klaba said a sufficiently privileged account could modify existing releases without passing CI/CD checks, BleepingComputer reported on October 20. The CI/CD pipelines with unit and functional tests and CVE detection were not impacted, but that did not help in this case because the attacker did not need the pipeline. The attacker uploaded a build directly onto the releases.

The detection story is also instructive. A customer did not run the binary. They used go version -m to read metadata and found a dirty pseudo-version built from commit 5ead8ef rather than tagged 760fd72, The Stack reported on October 19. That is a valuable signal: build metadata can reveal that an artifact does not match its tag. The customer also noticed that the account, HassenBF, was not a public member of the ovh org and did not appear among the repository's contributors. Those two observations together were enough to flag the release.

The attribution to GlassWorm is not confirmed by OVHcloud in the materials, and it should be treated as a research assessment rather than a settled fact. BleepingComputer reported on October 20 that OpenSourceMalware said the attack was likely part of a new GlassWorm operation. Researchers said the GitHub account had been compromised for more than half a year, with a scripted history rewrite on March 5, 2026, and a hidden preinstall.js loader that decodes a second stage using a Solana memo dead drop. If that assessment holds, the OVHcloud incident is not a one off. It is another example of attackers using trusted developer identities and release infrastructure rather than exploiting a software vulnerability.

Why It Matters

For OVHcloud users, the immediate task is credential hygiene. Klaba urged anyone who downloaded a compromised package to clean the system and revoke all secrets, warning that the binary was poor quality but could go all the way. The affected releases were v0.11.0 through v0.15.0; v0.10.0 and v0.16.0 were clean. The Hacker News reported on October 20 that Homebrew users were protected by a pinned SHA-256, while go install, source builds and the Docker image were unaffected. That leaves a narrower but still serious set of users who fetched the vulnerable archives directly during the window.

The broader lesson is about the trust model of package releases. Developers often treat a version number and a checksum file as proof of integrity, but both can be replaced if the release itself is mutable. In this case checksums.txt was replaced along with the binaries, so the published hashes matched the malicious files. The original SHA-256 for the Linux arm64 archive no longer matched the swapped archive's published hash, The Hacker News reported on October 20. Pinning a known good hash, as the Homebrew cask did, is one of the few controls that worked.

The incident also puts pressure on GitHub and on projects that rely on release assets. OVHcloud enabled release immutability after the fact, and the company considers the incident resolved. The Stack reported on October 19 that the OVHcloud CLI repository had seen just 14 commits over the past month, a detail that cuts both ways. A quiet repository can be easier to monitor, but it can also make an unexpected release change stand out only if someone is looking. The customer who reported the issue was looking, and that made the difference.

Next Up

OVHcloud said it was continuing research on the binary and would publish additional details shortly. Users who installed or updated the CLI during the 94 minute window should treat secrets on the affected machine as exposed, change those secrets, and remove or replace the compromised tool. The company has published a clean v0.16.0 as an immutable release and lists v0.10.0 as clean.

For the wider ecosystem, the open questions are whether GitHub release immutability becomes a default expectation for projects that ship binaries, and whether researchers can tie the OVHcloud swap to the GlassWorm activity that OpenSourceMalware described. BleepingComputer reported on October 20 that the account had been compromised for more than half a year and that a hidden preinstall.js loader used a Solana memo dead drop. Those details, if confirmed, would make this incident a case study in how far a stolen developer identity can reach.