Last updated: 24 October 2026. Sources are listed at the end.
Two incidents in the week of 19 October hit developers where it hurts most: their secrets. First, attackers swapped the official OVHcloud CLI for a password-stealing build for 94 minutes. Then Railway, a popular app hosting platform, said an attacker read and partly decrypted customers’ environment variables. This guide covers both incidents, explains who needs to act and shows how to rotate secrets in the right order.
The short answer
- OVHcloud CLI: if you downloaded a release binary of v0.11.0 to v0.15.0 on 19 October between 12:47 and 14:21 UTC (6:17 pm to 7:51 pm IST), treat that machine as compromised. Install v0.16.0.
- Railway: Railway asks every customer to roll all environment variables, create new API tokens and redeploy.
- In both cases, rotate keys first and investigate second.
Incident 1: OVHcloud CLI release swapped
What happened
An attacker hijacked a contributor’s GitHub account and replaced the release files for ovhcloud-cli v0.11.0 to v0.15.0 directly on GitHub, bypassing the normal build pipeline. They also replaced checksums.txt, so a checksum check would still pass. OVHcloud’s post-mortem traces the account takeover to a malicious VS Code extension that infected the developer’s personal Mac a year earlier.
The problem only affects downloads made during the 94-minute window. The attacker swapped these builds: macOS (arm64 and x86_64), Linux (arm64 and x86_64) and Windows x86_64. The attacker did not touch the Docker image, go install or the 32-bit, Windows arm64 and wasm builds.
What the stealer takes
The fake binary includes a stealer called “envchecker”. It collects:
- Credentials for AWS, GCP, Azure, DigitalOcean and Terraform
- Docker and Kubernetes configs, npm tokens,
.netrcand git config - SSH keys
- Tokens stored by editors and AI coding tools, such as VS Code, Cursor and Claude
It copies these to a temporary folder named envchecker- followed by digits, then uploads them to 45.32.148.174.
How to check
# Leftover staging folders (the malware never deletes them)
ls -d /tmp/envchecker-* "${TMPDIR:-/tmp}"/envchecker-* 2>/dev/null
# Hash the binary without running it, then compare with the advisory's MD5 list
md5sum "$(command -v ovhcloud)"On Windows, look for envchecker-* folders under %TEMP%. Compare the hash with the list in OVHcloud’s GitHub advisory GHSA-862f-55f5-vmvw. Also check outbound connections to 45.32.148.174 in your firewall logs.
What to do
- Delete the binary and install v0.16.0. Verify it with
gh attestation verify. - Revoke your OVH API keys (don’t just create new ones).
- Rotate cloud, Docker, Kubernetes, npm and Terraform credentials, plus SSH keys.
- Sign out of editors and AI tools and create fresh tokens.
Incident 2: Railway environment variables exposed
What happened
Railway’s preliminary report says an attacker queried customers’ encrypted environment variables. Using stolen CI credentials, they then decrypted a subset of them. The activity ran from 20 October 13:58 UTC to 22 October 03:32 UTC. Railway says the attacker did not access customer accounts, but it hasn’t ruled out access to source code.
Railway estimates that the attacker may have read variables in about 1.85% of workspaces. In particular, it believes the attacker wanted AI and platform API keys. Workspaces with many variables, or many AI vendor keys, are at the highest risk.
What Railway has done
Railway asked vendors such as GitHub, OpenAI, Anthropic and Stripe to revoke exposed keys. It also invalidated all Railway API tokens and OAuth sessions, rotated storage credentials and rolled its GitHub App installations. Railway paused builds and then restored them on 22 October.
What you should do
Railway’s advice applies to all customers, not just the 1.85%:
- Roll every environment variable: database passwords, API keys, webhook secrets and private registry credentials.
- Create new Railway API tokens and update your CI.
- Remove public network access from databases where you can.
- Review audit logs in GitHub, your registries, AWS and GCP for activity since 20 October.
- Redeploy after updating the secrets, so the running services use the new values.
Railway hasn’t published the root cause yet. It also hasn’t confirmed reports of drained crypto wallets.
How to rotate secrets after any incident
Both incidents show the same lesson: a leaked secret stays dangerous until you rotate it. Keep this list handy:
| Secret | Where to rotate | Don’t forget |
|---|---|---|
| Cloud keys (AWS, GCP, Azure) | IAM console | Instance roles, CI variables |
| AI provider keys | Provider dashboard | Usage limits and billing alerts |
| Database passwords | Database and app config | Read replicas, backups, cron jobs |
| Git and registry tokens | GitHub, GitLab, Docker Hub | Deploy keys, CI runners |
| SSH keys | authorized_keys on servers | Old keys left on other servers |
| Payment and webhook secrets | Stripe, Razorpay and similar | Webhook signing secrets |
Afterwards, watch bills and logs for a few weeks. Attackers often use stolen keys days later.
To make the next incident smaller, use short-lived credentials where possible, keep secrets in a manager rather than in .env files, and pin tool versions you install on developer machines. The same week also saw the LiteLLM 1.107.0 backdoor; our Black October fact-check covers the rest. For an outside review of how your team stores and rotates secrets, see our VAPT services.
Sources
- OVHcloud CLI security advisory GHSA-862f-55f5-vmvw
- The Stack: OVHcloud CLI repository compromised
- Safeguard: OVHcloud CLI release backdoor analysis
- Railway: preliminary report on the October security incident
- Railway: security disclosure, 21 October
- TechCrunch: Railway urges users to revoke secret keys
Want a second pair of eyes on your DevOps security? Our VAPT services cover CI/CD pipelines, self-hosted tools and how secrets are stored. For servers, see our Linux server hardening & security audit, or contact us.
