OVHcloud CLI v0.11.0–v0.15.0 release assets swapped with secret-stealing binary via hijacked GitHub contributor account

Linha do tempo

1. securityweek.com ↗ · pub. 21/10/2026 03:02 · coletado 21/10 05:00

   OVHcloud CLI supply chain compromise: hijacked developer GitHub account used to plant secret-stealing binary in v0.11.0–v0.15.0

   ler a análise desta fonte ocultar

   OVHcloud disclosed that an attacker used the hijacked GitHub account of one of its developers to overwrite releases of its official CLI tool with a secret-stealing binary on October 19. Versions v0.11.0 through v0.15.0 are listed as compromised, while v0.10.0 and the new v0.16.0 are clean. The malicious files appeared at 14:47 Paris time and were blocked at 16:21 (roughly 94 minutes) after a customer reported the issue; a failed automated hash check also exposed the tampering. OpenSourceMalware found that the contributor's account had likely been compromised since at least March 2026 and that a loader linked to a known GlassWorm wallet indicator was involved, but the researchers could not confirm that the same actor was behind both events, and OVHcloud has not mentioned GlassWorm.

   Technical Details

   • The attacker uploaded the binary over the original files of already published GitHub releases. The CI/CD pipelines were not impacted, because GitHub's release immutability option was not enabled and a user with sufficient permissions could modify existing releases directly.
   • Only builds for the most common platforms were replaced (macOS, 64-bit Linux, Windows x86_64). Researchers believe this points to credential harvesting on developer and operations workstations. OVHcloud founder Octave Klaba described the binary as poor quality but capable of retrieving secrets from disk.
   • In March 2026, four of the contributor's personal repositories were rewritten, three of them to include a hidden loader whose next stage queries the Solana blockchain for the location of a further payload, using a wallet that is a known GlassWorm indicator. Attribution to the same actor is the researchers' inference.
   • OpenSourceMalware could not obtain a payload sample before OVHcloud deleted the malicious files.
   • Affected users are those who installed or updated the CLI via the official install script, Homebrew or a direct GitHub download during the window. Users who built from source, used Go's install command or pulled the official Docker image are not affected.

   Remediation

   • Identify hosts that installed or updated the OVHcloud CLI on October 19, and upgrade to v0.16.0.
   • Treat secrets and credentials on affected machines as exposed and rotate them, including OVHcloud API credentials.
   • Enable GitHub release immutability, verify release hashes, and secure maintainer accounts. OVHcloud has already enabled the immutability option.
2. gbhackers.com ↗ · pub. 20/10/2026 08:03 · coletado 20/10 09:00

   OVHcloud CLI GitHub repository compromised via developer account to distribute secret-stealing binary

   ler a análise desta fonte ocultar

   OVHcloud disclosed a supply-chain attack on its command-line interface (CLI) repository on GitHub. An attacker used a compromised developer's GitHub account to insert a malicious binary designed to retrieve secrets from users' disks. CEO Octave Klaba confirmed the incident on 19 October 2026 after a customer report. The compromised release was identified at 14:47 and detected and blocked by 16:21, a 94-minute exposure window. OVHcloud has not yet confirmed how many customers were affected, whether data was exfiltrated, or how the developer account was compromised.

   Technical Details

   • Affected CLI versions: v0.11.0, v0.12.0, v0.13.0, v0.14.0 and v0.15.0. v0.10.0 and the upcoming v0.16.0 are reported as not compromised.
   • The attacker added a binary that searches the disk for secrets. Klaba described it as poor quality but effective for its purpose.
   • A customer flagged suspicious activity involving an account named HassenBF, which was not publicly listed as an OVH organization member or repository contributor. The customer also questioned modifications to release assets (a "dirty build") and recommended treating published assets as immutable.
   • Initial checks found no other affected repositories. The investigation into the account compromise, the targeted files and possible exfiltration is ongoing.
   • The repository did not have private vulnerability reporting enabled, so the customer raised the issue publicly.

   Remediation

   • Users who downloaded the CLI on 19 October 2026 should update immediately or delete it.
   • Rotate all secrets stored on the disk of any affected system, since replacing the executable alone does not complete recovery.
   • Treat published release assets as immutable, issue new versions instead of overwriting files, and enable private vulnerability reporting on repositories.
3. bleepingcomputer.com ↗ · pub. 20/10/2026 08:31 · coletado 20/10 09:00

   OVHcloud CLI releases 0.11.0-0.15.0 backdoored on GitHub after developer account hijack, stealing secrets from disk

   ler a análise desta fonte ocultar

   OVHcloud disclosed that attackers hijacked a developer's GitHub account and used it to modify the open-source OVHcloud CLI repository, publishing trojanized releases 0.11.0 through 0.15.0 that carry information-stealing malware. According to CEO Octave Klaba, the malicious release appeared at 14:47 on October 19 and was detected and blocked at 16:21 after a customer report. The malware's purpose was to retrieve secrets from the disk of affected machines. OpenSourceMalware assesses that the activity is likely a new GlassWorm operation, though it did not analyze the delivered payload. OVHcloud considers the incident resolved, but anyone who ran an affected binary should treat all secrets on the machine as compromised.

   Technical Details

   • Compromised versions: v0.11.0, v0.12.0, v0.13.0, v0.14.0 and v0.15.0. Version 0.10.0 and the latest 0.16.0 are clean.
   • Root cause: GitHub's release immutability setting was disabled, so a sufficiently privileged account could alter existing releases without passing CI/CD checks. OVHcloud states that the CI/CD pipelines (unit and functional tests, CVE detection) were not impacted. OpenSourceMalware confirms the attacker did not tamper with the pipelines and uploaded locally built, infected packages.
   • The GitHub account used had reportedly been compromised for more than six months. Its public repositories show a scripted history rewrite on 5 March 2026 and a hidden preinstall.js loader that decodes to a second stage using a Solana memo dead drop. The associated wallet is a known GlassWorm indicator.
   • Affected platforms: macOS (Intel and ARM), Linux (x86_64 and ARM64) and Windows x86-64. Source builds and Docker images were not affected.

   Remediation

   • Update to 0.16.0 or remove the tool if a compromised version was downloaded.
   • Clean the affected system and revoke and rotate all secrets stored on the disk of any machine that ran an affected binary.
   • Enable GitHub's release immutability on release repositories (OVHcloud has done so).
4. thehackernews.com ↗ · pub. 20/10/2026 05:21 · coletado 20/10 07:00 primeiro registro

   Attacker hijacks contributor GitHub account to swap binaries on five OVHcloud CLI releases with secret-stealing build

   ler a análise desta fonte ocultar

   On 19 October 2026 an attacker used a hijacked contributor's GitHub account to replace the download archives on five existing releases (v0.11.0 to v0.15.0) of OVHcloud CLI. The swapped files were a build designed to steal secrets stored on the disk of any machine that ran it. They were live from 12:47 to 14:21 UTC (up to 94 minutes) for macOS, Linux x86_64/arm64 and Windows x86_64. OVHcloud deleted the files and published a clean, immutable v0.16.0. OpenSourceMalware links the compromised account to the GlassWorm campaign, but this is the researchers' own inference and no sample of the October binary was preserved. OVHcloud has not said which files the binary reads, where it sends them, how many copies were downloaded, or how the account was compromised; a postmortem is promised.

   Technical Details

   • The release workflow never ran. The attacker uploaded a plain go build of a later commit directly onto old releases, and also replaced checksums.txt so the published hashes matched. The source code, tags and CI/CD pipeline were not touched.
   • The attack worked because GitHub release immutability (generally available since October 2025, protects only releases created after it is enabled) was not enabled, so anyone with write access could replace release assets.
   • Exposed paths: the official install.sh (never checks a hash), manual downloads from release pages, CI jobs fetching archives without a pinned hash, and the CLI's own upgrade command on v0.12.0 to v0.14.0 installs on macOS/Linux set up by script or by hand.
   • Not exposed: Homebrew (the cask pinned the original SHA-256s; the tap's history shows no change), go install or source builds (the v0.15.0 tag still points to 760fd72), the Docker image (last pushed 21 September), and installs made before 12:47 UTC and not updated. The Linux i386, Windows i386, Windows arm64 and WebAssembly builds were not altered.
   • Indicators in go version -m output of the bad build: module version is the pseudo-version v0.15.1-0.20261013083505-5ead8ef9b43d+dirty, the recorded commit is 5ead8ef instead of 760fd72, and an -ldflags="-s -w" line is present. A +dirty marker or vcs lines alone do not indicate compromise: the clean v0.16.0 reports v0.16.0+dirty too.
   • The only published hash of a swapped file is the v0.15.0 Linux arm64 archive.
   • The CLI keeps OVHcloud API credentials in ~/.ovh.conf and environment variables, but all secrets on the disk are considered at risk.
   • A customer's CI job that pinned the SHA-256 of the Linux arm64 archive caught the swap and filed a public issue at 13:50 UTC. The files were deleted at 14:21 UTC and v0.16.0 was published at 17:16 UTC.
   • The hijacked account is a contributor to OVHcloud's documentation repository. Four of its personal repositories were force-pushed on 5-6 March with a loader reading a Solana wallet memo field, the wallet named in GlassWorm's ForceMemo campaign.

   Remediation

   • If a swapped build was run, or you cannot tell, treat every secret readable from that machine as exposed and rotate it, preferably from a different machine.
   • Remove the binary and install v0.16.0, which is immutable and carries a release attestation; verify archives with gh release verify-asset v0.16.0 FILE.
   • Pin SHA-256 hashes in CI and install scripts, and enable release immutability on GitHub repositories.
   • Do not run a suspect binary to check its version; inspect it with go version -m.