What happened
OVHcloud’s open-source command-line interface (CLI), a tool administrators and developers use to manage cloud and hosting services from a terminal and automate tasks, was compromised. BleepingComputer reported that attackers used access to a developer’s GitHub account to modify published releases, distributing versions containing information-stealing malware. The incident was a software supply-chain attack: users could receive malicious code through a familiar project release rather than from an obviously suspicious download site. BleepingComputer’s report
OVHcloud CEO Octave Klaba said the compromised release appeared on October 19, 2026, at 14:47 and was detected and blocked at 16:21 after a customer report, according to BleepingComputer. The exposure window was short, but it does not establish how many people downloaded or ran the affected binaries. Any system that executed one should be treated as potentially exposed. BleepingComputer’s account of Klaba’s statements
Affected versions and platforms
OVHcloud identified CLI versions 0.11.0, 0.12.0, 0.13.0, 0.14.0 and 0.15.0 as compromised. BleepingComputer reported that OVHcloud identified version 0.10.0 and the subsequent 0.16.0 release as clean. Do not assume a package is safe simply because it was downloaded from the project’s GitHub release page: the issue was precisely that published releases had been altered. BleepingComputer’s reporting on OVHcloud’s version guidance
OpenSourceMalware’s analysis, as reported by BleepingComputer, identified affected binaries for macOS on Intel and ARM, Linux on x86_64 and ARM64, and Windows x86-64. The researchers reported that source builds and Docker images were unaffected. That distinction should not be used as a reason to dismiss possible exposure: use the exact artifact and version history for the installation in question, and treat any affected binary that was run as suspect. BleepingComputer’s summary of OpenSourceMalware’s findings
BleepingComputer reported that the compromised binaries were capable of retrieving secrets from disk. Its report characterized the malware as relatively poor quality, but that is not a meaningful safeguard. A weak or incomplete stealer may still access credentials, keys, tokens, configuration files or other sensitive material available to the user account. BleepingComputer’s reporting
What is known about the compromise
OVHcloud said the attacker hijacked a developer’s GitHub account and altered releases. Klaba said the company’s CI/CD pipelines—including unit tests, functional tests and CVE detection—were not impacted, according to BleepingComputer. Separately, OpenSourceMalware researchers said the malicious packages were uploaded after being built locally rather than through the normal pipeline, as reported by BleepingComputer. These are distinct statements and findings; clean pipeline results did not guarantee that the release artifacts users received were trustworthy. BleepingComputer’s account of OVHcloud’s statements · BleepingComputer’s summary of OpenSourceMalware’s findings
Klaba later disclosed that GitHub’s release immutability setting had been disabled, according to BleepingComputer. Without that control, a sufficiently privileged account could modify existing releases without passing through the expected CI/CD checks. OVHcloud said it enabled release immutability after the incident and considered the compromise resolved. That change reduces the chance that published release assets can be silently replaced, but users still need to address credentials potentially exposed during the earlier window. BleepingComputer’s reporting on Klaba’s statements
OpenSourceMalware researchers assessed that the activity was likely part of a new GlassWorm operation, a name associated with campaigns targeting software-development ecosystems including VSCode, OpenVSX, GitHub and npm. BleepingComputer reported the researchers’ assessment that the GitHub account involved had been compromised for more than six months. The researchers also reported that its public repositories showed a scripted history rewrite on March 5, 2026, and a concealed preinstall.js loader that decoded to a second stage using a Solana memo dead drop. They noted an associated wallet was a known GlassWorm indicator; they did not analyze the payload delivered through the trojanized OVHcloud CLI. This is a reported researcher assessment, not confirmation that every detail of this incident or payload has been established. BleepingComputer’s summary of OpenSourceMalware’s analysis
If you downloaded or ran an affected release
OVHcloud’s advice, as reported by BleepingComputer, is that users who downloaded a compromised CLI package should clean up the system and revoke all secrets. If you ran one of versions 0.11.0–0.15.0, act on the assumption that secrets accessible on that machine may have been exposed. Merely deleting the CLI does not undo access that malware may already have had, and reinstalling a clean version does not invalidate copied credentials. BleepingComputer’s reporting on OVHcloud’s advice
A practical response should be coordinated with the teams responsible for the relevant systems:
- Contain the affected host. Stop using the compromised CLI and isolate the machine from sensitive production networks where feasible. Preserve relevant logs and evidence under your incident-response procedures before rebuilding or cleaning the device.
- Identify the exposure. Check installed version, the source and time of download, whether the binary was executed, and which user account ran it. Determine what credentials and files were accessible to that account. Include developer workstations, build agents and automation hosts in the review.
- Revoke and replace secrets. Rotate cloud API credentials, access tokens, SSH keys, deployment secrets and other credentials that were present or accessible. Revoke first where supported; then issue replacements and update dependent services, pipelines and applications. Prioritize credentials with production or administrative permissions.
- Review for misuse. Examine cloud audit trails, authentication records, source-control activity and CI/CD logs for unusual access, new keys, unexpected deployments or changes. Monitor replacement credentials closely after rotation.
- Restore from a trusted state. Follow organizational incident-response guidance to remove or rebuild affected systems. Obtain any replacement software from a verified clean release and validate its version and artifact provenance before use.
These steps are prudent containment guidance based on the reported ability to retrieve disk secrets; they are not a claim that every listed credential type was stolen in every case. The scope depends on what was present and available when the binary ran. If the package was downloaded but never executed, assess that separately, while still verifying whether any other affected artifact was launched.
Lessons for software release security
The incident demonstrates why code-repository protections and build-pipeline protections must be considered together. Testing can validate source or a build process, but a release asset modified outside that process can bypass the assurances those checks provide. Release immutability, tightly scoped account permissions, strong authentication and review of release changes help protect the final artifacts users actually download.
For organizations consuming command-line tools, maintain an inventory of versions and installation sources rather than relying on memory or a developer’s local shell history. Pin known versions where practical, record artifact hashes or provenance where available, and monitor vendor security announcements. These controls do not eliminate risk, but they make it faster to answer the key incident questions: which machines received the affected version, whether it ran, and what credentials require rotation.
OVHcloud said it enabled GitHub release immutability and considered the incident resolved, as reported by BleepingComputer. That addresses an important release-control weakness; it does not certify that previously exposed machines or credentials are safe. Users who ran a compromised version should prioritize cleanup and secret rotation, as the company advised. BleepingComputer’s reporting on OVHcloud’s response
Sources
- BleepingComputer. “OVHcloud CLI releases backdoored on GitHub to steal developer secrets.” Reporting on OVHcloud’s statements and OpenSourceMalware researchers’ findings. https://www.bleepingcomputer.com/news/security/ovhcloud-cli-releases-backdoored-on-github-to-steal-developer-secrets/
The article’s descriptions of OVHcloud’s statements and OpenSourceMalware’s findings are attributed through BleepingComputer’s reporting; this source list does not imply independent verification of those underlying statements or findings.
