GlassWorm injects malware into OVHcloud CLI releases via GitHub account compromise

1. Executive summary

On 19 October 2026 an attacker used a compromised GitHub account belonging to an OVHcloud contributor to replace the download archives on five existing releases of the OVHcloud command-line interface (CLI), versions v0.11.0 through v0.15.0, with a binary built to retrieve secrets from disk. The tampered assets were live for up to 94 minutes, from 12:47 to 14:21 UTC, and were removed after a customer reported a failed hash check. No CVE has been assigned and the item carries no CVSS score or CISA KEV entry; the exposure is a supply-chain compromise of a developer tool, not a software vulnerability. Any EMEA financial services firm whose engineering or platform teams installed or updated the OVHcloud CLI through the install script, Homebrew or a GitHub tarball during that window on macOS, Linux x86_64/arm64 or Windows x86_64 should treat every secret on the affected workstation as disclosed. OpenSourceMalware attributes the activity to GlassWorm; that attribution is single-sourced and OVHcloud has not confirmed it.

2. Regulatory framing

3. Technical analysis & attack chain

1. An attacker obtained access to the GitHub account of a legitimate OVHcloud contributor. OpenSourceMalware assesses the account had been compromised since at least March 2026, roughly seven months before the October incident.
2. In March 2026, the history of several of that account's personal repositories was rewritten, and a hidden loader was planted in three of them. The loader fetched its next stage by querying the Solana blockchain for a payload location, using a wallet that is a known GlassWorm indicator.
3. On 19 October 2026, using the same account's permissions, the attacker uploaded a malicious binary over the original download archives of five already-published CLI releases, v0.11.0 through v0.15.0. The source repository was not touched and the CI/CD pipeline was not involved: the binary was built on a workstation and pushed directly onto the release assets.
4. The replacement was possible because GitHub's release immutability option was not enabled on the repository. With immutability off, an account holding the right permissions can modify an existing release without any check from OVHcloud's CI/CD, which is why unit tests, functional tests and CVE detection never saw the change.
5. The tampered assets went live at 12:47 UTC (14:47 Paris time) and were blocked at 14:21 UTC (16:21 Paris time), a window of up to 94 minutes. A customer reported the problem after an automated hash check failed, and OVHcloud deleted the malicious files.
6. Only builds for the most common platforms were replaced: macOS, Linux x86_64/arm64 and Windows x86_64. Users who installed through install.sh, brew install --cask ovh/tap/ovhcloud-cli, or a direct tarball download from GitHub in that window received the malware. Users who built from source, installed through the Go module proxy or Go's install command, or pulled the official Docker image were not affected.
7. OVHcloud enabled release immutability after the incident and considers it closed. Version v0.10.0 was unaffected and the new v0.16.0 release is clean.

The payload itself was not recovered. OVHcloud deleted the malicious files before anyone could archive them, so OpenSourceMalware has not analysed the binary and no capability beyond "retrieve secrets from the disk" is confirmed. OVHcloud CEO Octave Klaba described the binary's quality as poor but said it "can go all the way". OpenSourceMalware's judgement that this is credential harvesting aimed at developer and operations workstations rests on the platforms the attacker chose, not on payload analysis. Treat the stealer's exact targets (SSH keys, cloud credentials, environment files, shell history, package registry tokens) as unconfirmed.

Attribution to GlassWorm is single-sourced. OpenSourceMalware ties the October attack to GlassWorm through the Solana wallet used in the March loader, but states explicitly that the link between the March account compromise and the October release replacement is its own inference. OVHcloud has not mentioned GlassWorm. GlassWorm has no MITRE ATT&CK profile, so the attribution is unconfirmed and should not drive blocking or hunting decisions on its own.

One timing discrepancy exists across sources: The Hacker News gives the live window as 12:47 to 14:21 UTC, while Help Net Security and SecurityWeek give 14:47 to 16:21 Paris time. The two are consistent once the UTC/Paris offset is applied; the 94-minute duration is the same in all three.

4. Mitigation & containment

P1 within 24 hours

• Query endpoint and package-manager telemetry for any execution of the OVHcloud CLI at version v0.11.0 through v0.15.0 on macOS, Linux x86_64/arm64 or Windows x86_64 between 12:47 and 14:21 UTC on 19 October 2026. Check Homebrew install receipts, shell history for install.sh invocations, and browser or proxy logs for tarball downloads from the OVHcloud CLI GitHub releases page in that window.
• On every confirmed or suspected host, rotate all secrets stored on disk: SSH private keys, cloud provider access keys, API tokens, package registry credentials, CI/CD secrets held locally, database passwords in environment files and credential helper stores. OVHcloud's own guidance is to change all secrets on the disk.
• Isolate confirmed hosts from the network pending forensic review. Do not reimage before capturing volatile state and the installed CLI binary for hash comparison.
• Upgrade any remaining installation to v0.16.0, which OVHcloud states is clean, or remove the CLI entirely.

P2 within 72 hours

• Add a detection rule for the OVHcloud CLI version range and for the install paths (install.sh, brew install --cask ovh/tap/ovhcloud-cli, direct tarball) so that any residual install is caught.
• Review GitHub organisation and repository settings for release immutability across all projects the firm publishes or consumes, and enable it where absent. The OVHcloud root cause was a disabled immutability control, and the same gap can exist in the firm's own release process.
• Where the firm consumes third-party CLI tools, add hash verification against the upstream source (Go module proxy, signed release manifest) before deployment rather than trusting the release asset alone.

P3 within 7 days

• Add supplier release-integrity controls to the third-party risk assessment for developer tooling, covering whether the supplier enforces release immutability and publishes verifiable hashes.
• Review whether developer workstations hold long-lived cloud credentials that could be replaced with short-lived, scoped tokens, since the stealer's value depends on what secrets sit on disk.

5. Indicators of compromise

No atomic indicators (file hashes, domains, IPs, URLs) are present in the source material. OVHcloud deleted the malicious files before they could be archived, and no hash, filename or network indicator was published. The Solana wallet referenced as a known GlassWorm indicator is not given a value in any source, so it cannot be listed.

Behavioural indicators:

6. Detection

No file hash, filename, mutex, registry key or distinctive string from the malicious binary is available, because the payload was deleted before analysis. A YARA rule cannot be written from the source material without fabricating strings. Detection therefore rests on version and install-path behaviour, expressed as a Sigma rule.

title: OVHcloud CLI Compromised Version Execution
id: 8f3c2a91-4d7e-4b1a-9c6f-2e5d8a0b7c14
status: experimental
description: Detects execution or installation of OVHcloud CLI versions v0.11.0 through v0.15.0, the releases replaced with a secret-stealing binary on 19 October 2026 between 12:47 and 14:21 UTC.
author: Adverse Trace
date: 2026-10-21
references:

  - https://www.helpnetsecurity.com/2026/10/21/ovhcloud-cli-github-malware/
  - https://www.securityweek.com/hijacked-developer-account-used-to-plant-stealer-in-ovhcloud-cli/
logsource:
  category: process_creation
detection:
  selection_cli:
    Image|endswith:

      - '/ovhcloud-cli'
      - '\ovhcloud-cli.exe'
  selection_version:
    CommandLine|contains:

      - 'v0.11.0'
      - 'v0.12.0'
      - 'v0.13.0'
      - 'v0.14.0'
      - 'v0.15.0'
  selection_install:
    CommandLine|contains:

      - 'install.sh'
      - 'brew install --cask ovh/tap/ovhcloud-cli'
  condition: selection_cli and (selection_version or selection_install)
falsepositives:

  - Legitimate use of a clean v0.16.0 or later build (version strings will not match)
  - Build-from-source installs (not affected, but may reference the version string)
level: high

The version strings and install commands above are taken verbatim from the sources. The rule will not match a clean v0.16.0 install. It will also not match a tampered binary that reports a spoofed version, so pair it with the install-window and hash-check telemetry described in §4.

7. Sources

• Help Net Security, "Info-stealing malware slipped into OVHcloud CLI releases on GitHub", 2026-10-21. https://www.helpnetsecurity.com/2026/10/21/ovhcloud-cli-github-malware/
• SecurityWeek, "Hijacked Developer Account Used to Plant Stealer in OVHcloud CLI", 2026-10-21. https://www.securityweek.com/hijacked-developer-account-used-to-plant-stealer-in-ovhcloud-cli/
• The Hacker News, "Hackers Hijack Five OVHcloud CLI Releases to Distribute Secret-Stealing Malware", 2026-10-21. https://thehackernews.com/2026/10/hackers-hijack-five-ovhcloud-cli.html

8. Adverse Trace position

No CVE has been assigned and there is no CVSS score or CISA KEV entry, so severity is assessed from exposure rather than a vulnerability score: a secret-stealing binary ran on developer and operations workstations for up to 94 minutes, and the affected population is only knowable by checking install history. The attribution to GlassWorm is single-sourced to OpenSourceMalware and rests on a Solana wallet link the analysts themselves describe as inference; GlassWorm has no MITRE ATT&CK profile, so we treat the attribution as unconfirmed and will not use it to drive blocking. Client impact is concentrated in firms whose engineering teams use the OVHcloud CLI and hold long-lived cloud or CI/CD credentials on developer workstations. Adverse Trace will monitor for a published payload analysis or hash set from OVHcloud or OpenSourceMalware and update this advisory if one appears, and will re-issue if OVHcloud confirms or contradicts the GlassWorm link. Clients who confirm execution on systems supporting critical functions should treat the DORA Art. 19 classification as live and contact us for incident support.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.