Coder registry breach steals cloud credentials
Attackers hijacked Coder's Terraform module registry to push fake packages that stole cloud credentials from developers' workspaces. The attacker redirected some registry traffic to their own servers, which hosted malicious code that grabbed secrets and sent them to a fake Coder domain.
- Severity
- Not scoredNo CVSS score recorded
- Affects
- Terraform
How it works
- An attacker gained control of Coder's Cloudflare setup and added their own servers to the registry's traffic pool.
- When developers pulled workspace templates or modules from registry.coder.com, they instead got fake packages with code that looked for cloud credentials in their Terraform environment.
- The malicious code then sent those credentials to a fake domain, which the attacker controlled.
What to do
Check if you used registry.coder.com to create, update, or deploy a workspace template between 07:35 UTC and 21:45 UTC on August 31, 2026. If you did, check for any unauthorized access to your cloud accounts. Also, if you ran a dry run of a template during that window, your environment could have been checked for secrets.
If you used the registry during the attack window, review your cloud credentials immediately and rotate them. Coder has disabled Terraform module caching to prevent further exposure. For more details, consult Coder's official security advisory.
Technical details
An attacker compromised Coder's Cloudflare infrastructure to redirect traffic from the official Terraform module registry (registry.coder.com) to a malicious server between 07:35 UTC and 21:45 UTC on August 31, 2026. The hijacked registry hosted modified Terraform modules containing credential-stealing code, which targeted secrets exposed to the Terraform provisioner environment, including environment variables, OIDC tokens, SSH keys, and one-time authentication tokens. The attacker used a lookalike domain, coder-infra[.]com, to exfiltrate stolen data via an HTTP endpoint (www[.]coder-infra[.]com/cli/check) while evading detection through an X-CLI-Token header.
The associated malicious IP address was 199.91.220[.]205. Organizations were at risk if they imported templates, updated versions, ran dry runs, or deployed workspaces during the attack window.