Hijacked Developer Account Used to Plant Stealer in OVHcloud CLI

French cloud hosting provider OVHcloud released version 0.16.0 of its official command-line interface after an attacker hijacked a developer GitHub account to distribute a secret-stealing binary across published releases. The supply chain incident occurred on October 19, affecting versions v0.11.0 through v0.15.0 before engineers removed the files. According to SecurityWeek's report, the intruder uploaded modified binaries directly over existing release assets without triggering continuous integration checks.

This report details the release asset overwrite, the forensic timeline reaching back to March 2026, and the impacted deployment methods. Systems administrators, DevOps engineers, and cloud architects utilizing the OVHcloud command-line client should audit their local installations immediately to assess credential exposure. The following sections examine how the malicious binary operated, which platforms received the payload, and how repository settings were adjusted to secure future releases.

Hijacked Developer Account Used to Plant: what actually changed

The intrusion came to light when an automated hash verification check failed during an installation, prompting an external user to flag the discrepancy publicly on GitHub. OVHcloud founder Octave Klaba acknowledged the breach on X, disclosing that an attacker had taken control of a legitimate contributor account with repository permissions. Rather than committing code or cutting a new tag, the intruder systematically replaced precompiled binaries on releases from v0.11.0 through v0.15.0. Version 0.10.0 remained clean, and OVHcloud promptly distributed version 0.16.0 as a safe replacement.

Because the threat actor altered existing release artifacts directly rather than committing code to the repository, continuous integration and deployment pipelines never detected the intrusion. Octave Klaba explained that the underlying administrative failure stemmed from GitHub release immutability setting being left disabled on the project. Without this safeguard enabled, any contributor with release permissions could overwrite compiled binary files without triggering automated continuous integration testing or alerting engineers. OVHcloud resolved the configuration gap immediately after the incident by enabling release immutability to prevent retroactive file modifications across all tags.

Hijacked Developer Account Used to Plant: how it works

The malicious binary uploaded across the compromised release tags was built to harvest local secrets, credentials, and authentication tokens from operator machines. In a public statement regarding the incident, Octave Klaba observed that while the code quality of the planted binary was poor, the program could successfully retrieve target secrets from disk. Security researchers at OpenSourceMalware confirmed that the attacker selectively replaced compiled binaries for the most common operating systems, pointing toward a coordinated effort to capture administrative credentials from developer and operations workstations.

OpenSourceMalware discovered that the compromised developer account had been under adversary control since at least March 2026, when four personal repositories belonging to the contributor were altered. Three of those personal repositories were modified to embed a hidden loader that queried the Solana blockchain to locate subsequent payloads. That query relied on a cryptocurrency wallet address identified as an established GlassWorm indicator. However, researchers could not verify that the March compromise and the October attack involved the same actor, noting that the link represents their own analytical inference.

Hijacked Developer Account Used to Plant: why it matters now

Software supply chain defense often focuses on source code reviews and continuous integration testing, but this attack highlights the vulnerability of mutable release distribution channels. Attackers can bypass pull request reviews and static security scanning entirely by substituting precompiled release assets after automated build pipelines finish. Because the continuous integration system was never invoked during the manual asset overwrite, automated scanning tools detected no suspicious commits. When release assets lack immutability protections, malicious files can sit on trusted distribution platforms without triggering alarms until client-side checksums fail.

Command-line cloud management clients represent high-value targets because they operate in environments rich in sensitive administrative credentials. Developers and system operators routinely execute these tools on machines storing API tokens, cloud access keys, and administrative configuration files. A secret-stealing binary planted inside an administrative utility can harvest those credentials directly from disk, potentially exposing entire cloud environments to unauthorized access. While OVHcloud removed the poisoned binaries before analysts could capture full payload samples, the incident demonstrates how contributor account takeovers can compromise downstream operational environments.

Hijacked Developer Account Used to Plant: who is affected

The exposure window was limited to a period of roughly 94 minutes on October 19, starting when the altered files appeared at 14:47 Paris time and ending at 16:21 Paris time when downloads were blocked. Users who installed or updated the command-line interface on macOS, 64-bit Linux, or Windows x86_64 systems during that specific window were exposed to the malicious binary. Impacted distribution paths include downloads from the official install script, the Homebrew package manager, and direct binary downloads from GitHub release pages.

Several installation channels and version configurations remained completely safe from the supply chain attack. Operators who built the binary directly from source code, installed the tool via Go install commands, or deployed the official Docker container were not affected. Additionally, systems running version 0.10.0 or older releases were outside the scope of the incident, as the attacker only targeted releases between v0.11.0 and v0.15.0. Any deployment where installations did not occur during the 94-minute window also avoided downloading the compromised files.

Hijacked Developer Account Used to Plant: what to watch

Administrators maintaining installations updated during the October 19 window must immediately upgrade to version 0.16.0 or downgrade to version 0.10.0. Beyond replacing the binary, security personnel should treat systems that ran the tool between 14:47 and 16:21 Paris time as potentially compromised. Recommended mitigation steps include rotating OVHcloud API credentials, authentication tokens, and administrative keys stored on the affected workstations. Incident response teams should also review workstation system logs, process execution records, and outbound network connections for evidence of data exfiltration or unauthorized access attempts.

Development organizations must verify that GitHub release immutability settings are enabled across all open-source and enterprise repositories to block retrospective asset modification. Security researchers will continue monitoring the Solana wallet indicators to determine whether the March GlassWorm-linked activity connects directly to the October supply chain incident. OVHcloud has not mentioned GlassWorm in its official updates, leaving attribution unconfirmed. Teams managing cloud infrastructure should monitor further disclosures from OVHcloud and OpenSourceMalware while auditing access controls and multi-factor authentication across all contributor accounts.