Executive Summary
On October 19, 2026, attackers hijacked a contributor's GitHub account and silently replaced download archives across five OVHcloud CLI releases (v0.11.0–v0.15.0) with a malicious binary designed to steal secrets stored on disk. The tampered files were live for up to 94 minutes before a customer's hash-pinning CI job detected the discrepancy and filed a public issue. The attack exploited the absence of GitHub's immutable-release setting, allowing anyone with repository write access to overwrite existing release artifacts without triggering the CI/CD pipeline. Affected users on macOS, Linux x86_64/arm64, and Windows x86_64 who installed or auto-upgraded during the window were advised to rotate all credentials immediately.
This incident highlights a deepening supply-chain threat targeting developer toolchains: attackers are increasingly compromising trusted contributors rather than the build pipeline itself, bypassing conventional CI/CD controls. The campaign has been tentatively linked to GlassWorm, a threat actor known for hiding loader code in Unicode characters and abusing blockchain memo fields for C2 staging, signaling a sophisticated, multi-stage offensive posture against open-source ecosystems.
Why This Matters Now
Supply-chain attacks against CLI tools and package registries are accelerating in 2026, with threat actors targeting the contributor identity layer rather than the build pipeline. GitHub's immutable-release feature—generally available since October 2025—was not enabled, a gap now exploited at scale. Organizations relying on auto-update scripts without hash verification remain acutely exposed, and the GlassWorm link suggests a coordinated campaign with blockchain-based C2 infrastructure that evades traditional egress controls.
Attack Path Analysis
Attackers compromised a GitHub contributor account (likely via credential theft linked to the GlassWorm campaign) and used its write access to silently replace binary archives on five existing OVHcloud CLI releases with a secret-stealing payload, exploiting the absence of GitHub release immutability and hash verification in the official install script. Any developer or CI pipeline that downloaded or auto-updated the CLI during the 94-minute window on October 19 received a trojanized binary that read secrets from disk and exfiltrated them, with no integrity check in place to block or alert on the substitution.
Kill Chain Progression
This analysis maps confirmed threat intelligence to the full cloud kill chain to show where defensive gaps would emerge as an attack progresses.
Initial Compromise
Description
A GitHub contributor account with write access to the OVHcloud CLI repository was hijacked, most likely through credential theft. Evidence ties the account to the GlassWorm ForceMemo campaign, which stole GitHub tokens at scale in March 2026 via force-pushed malware loaders hidden in Unicode characters. The attacker gained authenticated access to GitHub without triggering OVHcloud's CI/CD pipeline, as release file replacement does not invoke workflow runs.
MITRE ATT&CK® Techniques
Compromise Software Supply Chain
Valid Accounts: Cloud Accounts
Compromise Accounts: Cloud Accounts
Unsecured Credentials: Credentials In Files
Stage Capabilities: Upload Malware
Masquerading: Invalid Code Signature
Automated Exfiltration
Application Layer Protocol: Web Protocols
Potential Compliance Exposure
Mapping incident impact across multiple compliance frameworks.
NIST SP 800-53 Rev 5 – Supply Chain Protection / Supply Chain Controls and Plans
Control ID: SA-12 / SR-3
PCI DSS 4.0 – Software Integrity and Third-Party Risk Management
Control ID: Requirement 6.3.3 / 12.3.4
DORA (EU) 2022/2554 – ICT Third-Party Risk and Supply Chain Resilience
Control ID: Article 28 / Article 30
NIS2 Directive (EU) 2022/2555 – Security in Network and Information Systems Supply Chains
Control ID: Article 21(2)(e) — Supply Chain Security
CISA Zero Trust Maturity Model 2.0 – Software Supply Chain Integrity and Least-Privilege Access
Control ID: Applications Pillar — Pillar 3: Application Access / DevSecOps Integration
ISO/IEC 27001:2022 – Supplier Relationships and Secure Software Delivery
Control ID: A.8.30 — Outsourced Development / A.5.23 — Information Security for Use of Cloud Services
Sector Implications
Industry-specific impact of the vulnerabilities, including operational, regulatory, and cloud security risks.
Information Technology/IT
Supply-chain infostealer hijacking OVHcloud CLI exposes IT teams running automated CI/CD pipelines to credential theft, requiring urgent egress controls and zero-trust segmentation per NIST.800-53.SC-7 and ZTMM.Network.
Computer Software/Engineering
Software engineers using OVHcloud CLI in build pipelines face secret exfiltration risk; compromised API credentials demand immediate rotation and hash-verified dependencies aligned with PCI.4.0.3.5.1 and NIST.CSF.PR.DS-5.
Computer/Network Security
Security practitioners managing cloud infrastructure face GitHub release-integrity failures; inline IPS and multicloud visibility controls mapped to NIST.800-53.SI-4 and ZTMM.CrossCutting.Visibility are critical mitigations.
Financial Services
Financial services firms using OVHcloud CLI for cloud operations risk regulatory breach through stolen API secrets, with exfiltration-stage kill chain weights demanding PCI.4.0.3.5.1-aligned egress enforcement and anomaly detection.
Sources
- Hackers Hijack Five OVHcloud CLI Releases to Distribute Secret-Stealing Malwarehttps://thehackernews.com/2026/10/hackers-hijack-five-ovhcloud-cli.htmlVerified
- OVHcloud CLI v0.16.0 Clean Release on GitHubhttps://github.com/ovh/ovhcloud-cli/releases/tag/v0.16.0Verified
- GlassWorm Hacks OVHcloud CLI Tool - OpenSourceMalware Timelinehttps://opensourcemalware.com/blog/glassworm-hacks-ovh-clouds-cli-toolVerified
- GitHub Immutable Releases Generally Availablehttps://github.blog/changelog/2025-10-28-immutable-releases-are-now-generally-available/Verified
- GitHub: Verify Release Integrity with gh release verify-assethttps://docs.github.com/en/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/verify-release-integrityVerified
- GlassWorm ForceMemo Campaign - Force-Pushed Malware into Python Repositorieshttps://thehackernews.com/2026/03/glassworm-attack-uses-stolen-github.htmlVerified
- OVHcloud CLI Compromised - Next.ink Coveragehttps://next.ink/262824/le-client-en-ligne-de-commande-dovhcloud-compromis-par-un-pirate-sur-github/Verified
- OVHcloud CLI Getting Started Documentationhttps://docs.ovhcloud.com/en/guides/manage-and-operate/cli/getting-startedVerified
Frequently Asked Questions
Cloud Native Security Fabric Mitigations and ControlsCNSF
Based on the attack progression modeled above, these are the defensive controls that would constrain each stage.
Aviatrix Zero Trust CNSF is relevant here because the trojanized OVHcloud CLI binary relied on unrestricted outbound network access from developer machines and CI/CD runners to exfiltrate stolen credentials. By enforcing identity-aware segmentation and controlled egress policies across cloud workloads, Aviatrix would likely reduce the blast radius of any successful binary execution — constraining how far stolen secrets could travel and how many environments the payload could reach.
Control: Cloud Native Security Fabric (CNSF)
Mitigation: CNSF fabric-level visibility across cloud workload traffic may help surface anomalous outbound connection patterns originating from newly deployed or updated binaries, reducing the window in which a trojanized artifact goes undetected across cloud-connected environments.
Control: Zero Trust Segmentation
Mitigation: Zero Trust segmentation policies applied to CI/CD runner environments and developer workstations would likely limit the scope of what any single compromised identity can access across cloud infrastructure, reducing the effective privilege footprint even when a supply-chain identity is already abused.
Control: East-West Traffic Security
Mitigation: East-west traffic enforcement between CI/CD runners, build environments, and downstream cloud workloads would likely constrain the trojanized binary's ability to move laterally through interconnected pipeline stages or shared cloud infrastructure, reducing how many systems the payload could interact with after execution.
Control: Multicloud Visibility & Control
Mitigation: Multicloud visibility across egress paths from cloud-connected workloads would likely surface unexpected outbound connections to unrecognized or policy-violating endpoints, reducing the attacker's ability to establish reliable C2 communication from CI/CD runners or developer environments operating inside monitored cloud boundaries.
Control: Egress Security & Policy Enforcement
Mitigation: Egress security policies enforced at the workload level would likely constrain unauthorized outbound data flows from CI/CD runners and developer systems connected to cloud infrastructure, reducing the payload's ability to successfully transmit harvested credentials to attacker-controlled external destinations.
Had Zero Trust segmentation and egress controls been in place across affected cloud environments, the scope of credential exposure would likely have been narrowed — limiting which systems the payload could reach, which secrets it could access, and how much stolen material could be successfully transmitted outbound before policy enforcement intervened.
Impact at a Glance
Affected Business Functions
- Cloud Infrastructure Automation and Provisioning
- CI/CD Pipeline Integrity and Software Delivery
- API Credential and Secret Management
- Developer Workstation and Build Environment Security
Estimated downtime: 1 days
Estimated loss: N/A
Any secrets stored on disk of affected machines during the 94-minute exposure window are considered compromised. This includes OVHcloud API credentials stored in ~/.ovh.conf, environment variables containing authentication tokens, SSH keys, cloud access credentials, and any other secrets readable from disk on macOS, Linux x86_64/arm64, or Windows x86_64 systems where a swapped binary was executed. The malicious build was a secret-stealing infostealer compiled from an untagged October 13 commit, targeting users who installed or updated OVHcloud CLI versions v0.11.0 through v0.15.0 via the official install script or direct archive download without hash verification. The exact number of affected installs, exfiltration endpoints, and full scope of stolen data have not been publicly disclosed by OVHcloud as of the incident date.
Recommended Actions
Key Takeaways & Next Steps
- • Enforce egress security and policy enforcement at the network layer: Deploy CNSF egress controls with FQDN filtering and outbound traffic inspection so that any secret-stealing binary executing inside a developer machine, CI runner, or cloud workload cannot establish unauthorized outbound connections to unknown destinations — CNSF Egress Security maps directly to NIST.800-53.SC-18 and ZTMM.Data, and would have blocked or alerted on the payload's exfiltration attempt.
- • Apply multicloud visibility and anomaly detection across CI/CD pipelines: Use centralized traffic observability and copilot-driven anomaly detection (CNSF Multicloud Visibility & Control, NIST.800-53.AU-6) to baseline normal outbound call patterns from build and deploy environments; a sudden credential-file read followed by an outbound POST to an unknown endpoint from a CLI binary is a detectable behavioral anomaly that should trigger automated alerting.
- • Implement zero trust segmentation for build and developer environments: Apply identity-based microsegmentation (CNSF Zero Trust Segmentation, NIST.800-53.AC-6) to restrict what any CLI tool or build artifact can access post-execution — least-privilege workload policies should prevent a compromised binary from reading credential stores outside its declared scope and from initiating lateral connections to other internal services.
- • Deploy inline IPS with known-bad payload signatures on egress paths: CNSF Inline IPS (Suricata) positioned on egress from developer and CI environments can match signatures associated with known infostealer communication patterns and GlassWorm-family loaders, blocking exfiltration even when the binary passes initial integrity checks, aligned to NIST.800-53.SI-4 and PCI.4.0.6.4.1.
- • Activate cloud-native enforcement fabric controls for supply-chain artifact verification: Leverage CNSF Cloud Native Security Fabric distributed policy enforcement to mandate cryptographic attestation checks (e.g., GitHub release attestation verification via gh release verify-asset) as a gate in all automated pipelines, ensuring any artifact without a valid signed provenance record is blocked before execution — aligned to ZTMM.CrossCutting.Automation and NIST.CSF.ID.RA-3, directly addressing the root control gap exploited in this attack.
