An attacker used an OVHcloud developer's GitHub account to replace official downloads of the French cloud provider's command-line tool with a build designed to pull secrets off users' computers, SecurityWeek reported Wednesday. The exposure lasted about an hour and a half, but it shows how a single repository setting can decide whether a trusted download stays trustworthy, and why the computers of engineers who hold cloud keys are a prime target.
What Happened
The command-line interface, or CLI, is a program developers and operations staff use to manage OVHcloud services from a terminal. According to SecurityWeek, the attacker swapped the files attached to existing releases on Oct. 19. OVHcloud said versions 0.11.0 through 0.15.0 were affected; version 0.10.0 and the newly released 0.16.0 are clean. The tampered build appeared at 14:47 Paris time and was blocked at 16:21, after a customer reported the problem.
Users were exposed if they installed or updated the tool on macOS, Linux or Windows through the official install script, Homebrew or a direct GitHub download in that window. People who built from source, used Go's install command or ran the official Docker image were not affected.
OVHcloud founder and chief executive Octave Klaba said on X that the added program's job was to retrieve secrets from the disk, SecurityWeek and Help Net Security reported. He said the root cause was that GitHub's release-immutability option, which locks a published release so its files cannot be altered, had not been turned on, so someone with the right permissions could change existing releases without passing through the company's automated build and test pipeline. That pipeline was not affected, he said, and the option is now enabled. "If you are affected, please change all the secrets on your disk," Klaba wrote, according to Help Net Security, which reported that the company considers the incident closed.
Who Was Behind It
That remains unconfirmed. OpenSourceMalware, a community threat intelligence platform, wrote that the files were deleted and re-uploaded through GitHub's release interface, with no new code pushed and no automated workflow run, and that the release's checksum file was replaced as well. Because only builds for the most common platforms were swapped, the researchers believe the aim was harvesting credentials from developer and operations workstations. OVHcloud deleted the files before anyone could analyze them.
The researchers also found that the developer's account had been compromised since at least March 2026, when several of its personal repositories were rewritten to carry a hidden loader. That loader uses a cryptocurrency wallet that appears on public indicator lists for GlassWorm, a campaign that has targeted software developers. The researchers called the link between the March compromise and the October attack their own inference, and SecurityWeek noted that OVHcloud has not mentioned GlassWorm.
Why It Matters
The attack bypassed the controls companies usually trust. The source code was clean and the build pipeline untouched; only the finished files customers download were changed. For executives, that means the integrity of software deliveries depends on account security and release settings, not just code review. And because a developer's laptop often holds keys to production cloud accounts, one bad install can become a much larger breach.
OpenSourceMalware's guidance for users is concrete: check whether anyone installed or updated the tool in the window, including build systems that fetch release files; treat every secret on an affected machine as exposed and rotate it from a different computer, including OVHcloud API keys, other cloud credentials, SSH keys and stored tokens; then remove the binary and install version 0.16.0 or later. For software publishers, it recommends immutable releases, signed records of how each build was made, and a review of which personal accounts can publish.
What to Watch
Watch whether OVHcloud publishes a fuller incident report, whether any customer reports misuse of credentials taken in the window, and whether further analysis confirms or rules out the GlassWorm connection.
