A command-line tool is meant to make cloud infrastructure easier to control. But it can also sit close to the keys: developers and system administrators may use such tools alongside credentials that grant access to servers, storage and other services. That makes the OVHcloud incident unsettling for a reason beyond one tainted download: the software people trust to manage their systems can become a route to the secrets that protect them.
OVHcloud, a French cloud and hosting provider, says attackers hijacked a developer’s GitHub account and used it to tamper with releases of the company’s open-source command-line interface, or CLI. The tool lets users manage OVHcloud services from a terminal and automate routine tasks. Versions 0.11.0 through 0.15.0 were compromised; versions 0.10.0 and 0.16.0 were reported clean.
When a trusted release becomes the trap
The compromised release appeared at 14:47 on October 19 and was blocked at 16:21, after a customer raised the alarm, OVHcloud chief executive Octave Klaba said. The company described the malware’s purpose as stealing secrets stored on the computer. Researchers identified affected downloads for macOS, Linux and Windows, while source builds and Docker images were not affected.
“Secrets” in this setting can include credentials, access tokens or other sensitive data used to authenticate to systems. They are valuable because they can let an intruder act as an authorized user, rather than trying to break through a system’s defenses from the outside. OVHcloud urged anyone who ran an affected binary to clean the machine and revoke and replace every secret stored on it.
The attack’s route into the release process is as revealing as its payload. OVHcloud said its continuous integration and delivery pipelines—the automated checks that can test code and scan for known vulnerabilities—were not compromised. Researchers at the community threat-intelligence project OpenSourceMalware likewise said the infected packages had been built locally, outside those pipelines.
That distinction matters. Automated checks can help catch defects or suspicious changes in code that passes through them. But a published release is also a product of account permissions and release controls. OVHcloud said GitHub’s release immutability setting had been disabled, allowing an account with sufficient privileges to alter existing releases without going through the usual checks. The company has since enabled the setting.
A long-lived account, and a possible wider campaign
OpenSourceMalware said the account used in the incident had been compromised for more than six months. Its researchers found signs of a scripted rewriting of the account’s public repository history in March 2026, as well as a concealed preinstall.js loader that decoded into a second stage using what they described as a Solana memo “dead drop.”
A dead drop is a way to hide or retrieve information through an intermediary rather than communicating directly with a command server. That clue, along with a cryptocurrency wallet already associated with GlassWorm, led the researchers to say the OVHcloud attack was likely part of a new GlassWorm operation. The group has been linked to activity affecting software-development ecosystems including VSCode, OpenVSX, GitHub and npm since late 2025. The researchers did not analyze the payload delivered through the altered OVHcloud CLI, so the exact behavior beyond its secret-stealing purpose remains unclear.
The episode illustrates a difficult truth about modern software security: a project can have functioning tests and still distribute a dangerous release if the controls around publishing are weak. A pipeline is a checkpoint, not a force field. Protecting software means securing the accounts and permissions that can change what users ultimately download, as well as the code and tests that produce it.
For developers, a command-line utility may seem like a small convenience—a shortcut for work they could do elsewhere. Yet tools that connect to cloud accounts often operate close to valuable credentials. In that sense, the most important question is not simply whether a program passed its tests. It is who can change the version you trust, and what happens if they do?