OVHcloud CLI Compromised: Infostealer Distributed Through Hijacked GitHub Releases for 25 Minutes
On October 19, the official OVHcloud CLI utility was compromised when an attacker used a hijacked developer account to replace binaries in five already-published releases spanning v0.11.0 through v0.15.0. The malicious files were served for approximately 25 minutes between 15:47 and 16:12 Moscow time (12:47–13:12 UTC), affecting macOS, Linux x86_64/arm64, and Windows x86_64 builds while leaving rarer platforms untouched.
How the Attack Unfolded
The attacker leveraged the GitHub Releases API to overwrite existing artifacts without creating new tags or triggering GitHub Actions workflows. The final file uploaded was checksums.txt, ensuring the release page displayed matching hashes for the tampered archives. The install.sh script performed no hash verification, allowing any user running curl ... | sh or downloading directly from the release page to receive the infostealer.
The malware itself was a relatively simple infostealer designed to scan the local filesystem for secrets including OVH API keys, SSH keys, .kube/config, .npmrc, .netrc, and environment files. It was built from a dirty working copy of the repository, as evidenced by Go build metadata showing a pseudo-version and vcs.modified=true.
Why Hardcoded Hashes Provided Protection
Users who had pinned the original SHA-256 hash of ovhcloud-cli_Linux_arm64.tar.gz (5c2beb56…) in their CI pipelines detected the attack immediately when the new archive (3833daff…) caused builds to fail. The Homebrew cask in ovh/homebrew-tap also remained untouched, protecting users who installed via that channel. Those who built from source, used go install, or pulled the official Docker image were likewise unaffected.
Account Compromise Timeline
The compromised account HassenBF had been under attacker control since at least March 2025, when GlassWorm malware was deployed across multiple personal repositories using force-push amend commits. The same loader later used the Solana blockchain as a resilient C2 mechanism, reading memo fields from a specific wallet to retrieve the next-stage payload address. The account retained write access to the ovhcloud-cli repository until the October incident.
OVH has since enabled immutable releases and attestation for v0.16.0 and requested that affected users rotate all secrets discovered on compromised machines. A full post-mortem is expected in the coming days.
Related articles
Supply Chain Attacks Target Ledger Hardware Wallets with Evolving Backdoors
Ledger disclosed that sophisticated hardware backdoors discovered in multiple Nano X, Flex, and Stax devices enabled thieves to steal approximately 102 million dollars in cryptocurrency from roughly 315 accounts. The implants, initially found by hardware hacker Joe Grand in devices sold by unauthorized Southeast Asian sellers, have since appeared in units purchased from authorized resellers CryptoBilis and MediaMarkt. Later versions analyzed by Mark Karpeles feature custom flexible PCBs, LTE modules, and antennas engineered to intercept seed phrases and exfiltrate them over cellular networks. Evidence now points to deliberate compromise of the authorized supply chain rather than isolated tampering of returned units. Ledger has urged resellers to purchase only through verified channels and has suspended sales through CryptoBilis pending investigation, while users continue to report additional compromised devices across Europe.
Audit of 25 Package Managers Shows Only Two Verify Every Package's Integrity Against Compromised Repositories
A comprehensive test by Trail of Bits examined 25 popular package managers to determine whether they detect malicious code substituted by a compromised repository. The study found that fewer than half verify package integrity by default using lockfiles, and only two managers check the cryptographic hash of every downloaded package. Most managers either require manual configuration, use hashes insecurely, or lack any integrity checks even when lockfiles are present. Signature verification is even rarer, with only Go performing checks by default. The research used a Docker and mitmproxy testbed to simulate attacks while preserving realistic conditions. Results highlight significant gaps in supply-chain protections across ecosystems including JavaScript, Python, Ruby, Rust, and others. The findings also discuss limitations of current lockfile designs and emerging improvements in several communities.
Compromised ConnectWise Credential Used to Access 173 Microsoft 365 Environments in Supply Chain Attack
A compromised credential from ConnectWise Cloud Backup, formerly known as SkyKick Backup, was abused to access at least 173 partner and customer Microsoft 365 environments. Microsoft Threat Intelligence classified the incident as an active supply chain attack. The attacker bypassed password and multi-factor authentication by using a client assertion issued from the vendor environment, impersonating an already-approved application identity to obtain Microsoft Graph tokens. Access occurred on October 15 between 06:13 and 08:34 UTC, with the intruder enumerating environment identifiers sequentially at short intervals, indicating automated scripting against a prepared target list. The backup application's permissions covered Exchange, OneDrive, SharePoint, Teams, and directory information. In one environment, another vendor application was granted global administrator rights and planted secrets in two trusted applications valid until 2028. ConnectWise later disabled seven application identities, revoked affected certificates, and suspended Cloud Backup services.
OIDC Configured but GitHub Actions Still Vulnerable: Megalodon and actions-cool Attacks Expose Runner Risks
Even after widespread adoption of OIDC for temporary cloud credentials in GitHub Actions, two major attacks in May 2026 demonstrated that the approach remains insufficient on its own. Attackers compromised actions-cool/issues-helper by substituting action tags to execute malicious commits that read Runner.Worker memory. The Megalodon campaign injected malicious workflows into 5,561 public repositories, harvesting environment variables, credential files, kubeconfig, SSH keys, and OIDC tokens. OIDC eliminates long-lived AWS_ACCESS_KEY_ID secrets but leaves short-lived tokens exposed inside the runner during job execution. Four mandatory protection layers are now required: strict cloud trust policies using StringEquals on the sub claim, job-level id-token: write permissions, outbound traffic controls such as Harden-Runner, and CODEOWNERS enforcement on .github/workflows/. GitHub Environments with mandatory reviewers add an essential human-approval gate that would have disrupted the Megalodon attack path.