On 19 October 2026, a supply chain compromise replaced GitHub release binaries of the official OVHcloud CLI (ovhcloud-cli) with a credential stealer for about ninety minutes. Anyone who installed from GitHub, Homebrew, or the project’s install script in that window could have received malware instead of a cloud tool. The source repository was clean. The build pipeline was clean. The files on the release page were not.
OpenSourceMalware reconstructed the incident: timeline, how the assets were swapped, how the malicious build was identified, GlassWorm indicators, hashes. OVHcloud published a security advisory the next day, pulled the bad files the same afternoon, and shipped a clean immutable v0.16.0.
The rest of 2026 looks like this too. Bitwarden, Trivy, Axios, LiteLLM, Notepad++, now a cloud CLI. A trusted install path, a short window, a payload that reads the laptop, then a scramble to rotate secrets nobody had listed. What I want on the desk now is a first-hour sequence, because the next name will be different.
How to check if you installed the malicious OVHcloud CLI
You were exposed only if you installed or upgraded ovhcloud-cli between 12:47 and 14:21 UTC on 19 October 2026, versions v0.11.0 through v0.15.0. If you did not touch the tool that day, skip this incident.
Do not run the binary to check. Use the install timestamp, look in the temp directory for a folder named envchecker- followed by digits, and compare the file on disk with the hashes in the advisory. Indicators and forensics are in the OpenSourceMalware write-up. If any of that is ugly, treat the machine as compromised and start below. Confirmation can wait.
What to do after a CLI supply chain compromise
“Rotate everything” is correct and also useless at 16:00 on a Tuesday. It does not say what comes first or which machine you should be sitting at. This is the order I want in my head the next time a CLI, plugin, library, or image I installed is reported as poisoned.
Isolate the machine right now
Stop using the machine for anything that touches a password or a token. Disconnect it from the network. Do not wipe it yet. The artifact, its timestamp, the package manager log, and your shell history are what tell you how much was exposed.
Write down three answers before you rotate anything: which tool and version landed, at what time, and which credentials your user could read in that session. Environment variables, cloud CLI configs, kubeconfigs, SSH keys, editor stores, coding-agent state. If you cannot list them, you are already guessing.
Rotate credentials from a clean device
Revoke in this order, because a stolen session can undo a reset you just performed:
- Identity provider sessions and OAuth grants. Everything else hangs off these.
- Code hosting sessions, personal access tokens, and SSH keys. Repositories and releases can be rewritten with them.
- The credentials of the service the compromised tool manages directly.
- Other cloud providers, Kubernetes configs, and service accounts reachable from the same laptop.
- Package registry tokens, which would turn this into someone else’s supply chain problem.
- CI/CD secrets and everything that lives in a secrets manager.
Revoke sessions, not just passwords. A password reset that leaves an active refresh token evicts nobody. While you are in each system, copy the activity log for the time between install and revocation before it rolls over.
Rebuild the laptop within a day
Rebuild the machine from scratch. A laptop that ran an unknown payload under your user account is not a machine you clean. Restore data from a backup you trust, and re-issue credentials rather than bringing the old ones back. Install the replacement against a hash you did not take from the same page that served the first file.
Write the timeline within a week
Write the timeline while you still remember it, including the parts you could not determine. Decide whether the incident is notifiable, and tell the teams whose systems those credentials could reach. Change one thing in your own setup that would have made this faster.
Reduce exposure before the next poisoned CLI
A checksum next to the download helps against a corrupted file. It helps less when the same write access can replace checksums.txt. The person who caught this one had pinned the hash in their own CI. Record the hash of what you audited and check it on every install. A version number is a pointer that can be moved.
Upgrade tools that hold keys as a decision, not as background noise. Prefer signed artifacts, attestations, or a package manager that enforces hashes. Keep less to steal: short-lived credentials through single sign-on, scoped keys with an expiry, no long-lived secrets in dotfiles on the laptop you also browse from. If a single binary can read your entire cloud access, the release page is not your weakest link.
Watch the release pages of the tools that hold keys the way you already watch CVEs. The payload in this incident went after VS Code, Cursor, Claude, OpenCode, cloud CLIs, SSH, Terraform, and kubeconfigs. That list is the machine we actually use. I covered pipelines and registries in Supply Chain Attacks Won’t Stop, and the workstation in Shift Left Starts in the IDE.
Takeaways
You will not catch every supply chain hit in time. Pin what you install, keep fewer long-lived secrets within reach of one program, and have a rotation order plus a clean device ready before you need them.
The difference between a bad afternoon and a company-wide incident is rarely the sophistication of the malware. It is how much a single program could read, and how quickly you could revoke it.