Hackers Hijack OVHcloud GitHub Account to Distribute Secret-Stealing CLI Malware

Attackers compromised the GitHub account of an OVHcloud developer to distribute secret-stealing malware through the cloud provider’s official command-line interface releases on October 19, 2026. The incident represents a supply chain attack that targeted users downloading the trusted OVHcloud CLI tool for their development environments.

A customer discovered suspicious changes in the release assets and alerted OVHcloud, which blocked the malicious files within 94 minutes. According to Cyber Security News, the compromised files appeared at 14:47 and were neutralized by 16:21. The provider confirmed that no other repositories were affected by this specific intrusion attempt.

Scope and Technical Details

OVHcloud CEO Octave Klaba identified versions v0.11.0, v0.12.0, v0.13.0, v0.14.0, and v0.15.0 as containing the malicious binaries. He designated version v0.10.0 as clean and announced the availability of a safe v0.16.0 release on the official GitHub page. The new release is marked as immutable, preventing further unauthorized changes to its published files.

The attacker used an existing developer account to insert a malicious binary into the software distribution. This method placed the threat inside a trusted download location, making it difficult for users to suspect that a routine CLI update could expose local credentials. OVHcloud has not explained how the developer account was initially compromised by the threat actors.

Impact and Response

The added program was designed to retrieve secrets stored on the disks of infected computers. Klaba described the malware’s quality as poor but warned that it could still achieve its objective of harvesting sensitive data. The public issue listing identifies the report as issue #300, covering replaced assets for versions v0.13.0 through v0.15.0.

The customer who reported the issue noted concerns about release files being replaced with a “dirty build” of a later commit. In software development, this term generally signals changes beyond the recorded source revision. The reporter also questioned the account behind the changes and suggested that release files should be locked against replacement.

Because the repository lacked a private vulnerability reporting channel, the customer’s report was made public. The user stated they had switched to building through the Go module proxy while seeking clarification from the vendor. This incident follows similar supply chain threats, such as the fake Web3 accelerator attack using npm packages that Threat Times reported on October 19, 2026.

What should you do?

Users who downloaded the OVHcloud CLI between the appearance of the malicious files and their removal should verify their current version. Those running versions v0.11.0 through v0.15.0 should upgrade to v0.16.0 or revert to v0.10.0 immediately. Organizations should monitor for unauthorized access attempts using credentials that may have been stored on affected machines.

What to do and how to stay safe: OVHcloud

• Verify the version of the OVHcloud CLI installed on your systems and ensure it is either v0.10.0 or v0.16.0.
• Rotate any API keys, tokens, or credentials that were stored on machines that downloaded the affected versions.
• Monitor network logs for unusual outbound traffic that could indicate secret exfiltration by the malicious binary.
• Ensure your software repositories have private vulnerability reporting channels to encourage discreet disclosure of security issues.

Step-by-step guide: Social Engineering Warning Signs and How to Respond

General security guidance from the Threat Times newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Which versions of the OVHcloud CLI are affected by this malware?

Versions v0.11.0, v0.12.0, v0.13.0, v0.14.0, and v0.15.0 are confirmed to contain malicious files.

Is there a safe version of the CLI available now?

Yes, version v0.16.0 is available and marked as immutable, while v0.10.0 is also confirmed clean.

How long did the malware remain available before being blocked?

The malicious files were detected and blocked within 94 minutes of their appearance.