Attackers Hijacked Coder's Cloudflare Setup to Push Poisoned Terraform Modules
For 14 hours on August 31, some developers pulling from Coder's official registry got credential-stealing code instead of the real thing.
Key points
- Attackers broke into Coder's Cloudflare setup on August 31 and slipped rogue servers into the pool handling requests to registry.coder.com.
- Between 07:35 and 21:45 UTC, some users downloading Terraform modules from the registry got a tampered version carrying credential-stealing code.
- Stolen data was sent to a lookalike domain, coder-infra[.]com, and included cloud API keys, SSH keys, CI/CD credentials, and terminal history.
- Fixed releases are 2.37.0, 2.36.4, 2.35.7 and 2.34.9; Coder says customer data it holds was not touched, but it cannot see the attacker's logs.
- Coder's user base includes Dropbox, Palantir, Square, Mercedes-Benz, the U.S. government, and defence contractors.
Coder, the company behind a popular self-hosted platform that gives software developers ready-made cloud workspaces, has confirmed that criminals hijacked part of its delivery infrastructure and used it to hand out booby-trapped code to a slice of its users.
The incident, first reported by BleepingComputer, ran for about 14 hours on Monday, August 31.
If you have never touched Coder, the short version: big organisations use it so their developers can code inside a controlled cloud environment instead of on their own laptops. Dropbox, Palantir, Square, Mercedes-Benz, KKR, EnBW, and various U.S. government and defence outfits are named users. That is the blast radius we are talking about.
What actually happened?
Someone got inside Coder's Cloudflare account, which is the service that sits in front of registry.coder.com and directs traffic to the right backend server. The attacker quietly added their own servers to the pool. Cloudflare, doing what it is told, sent a portion of registry requests to those rogue machines.
Developers asking the registry for Terraform modules (pre-built recipes that tell cloud providers like AWS or Azure how to spin up infrastructure) got poisoned versions back. The malicious modules ran on the developer's machine and quietly rifled through it.
What did the malicious modules steal?
According to Coder's advisory, the modules scraped anything a developer machine tends to have lying around: cloud and AI service API keys, credentials used by build and deployment pipelines (CI/CD), SSH keys, one-time login tokens, secrets sitting in config files, terminal history, and, in some cases, Coder's own database passwords.
Everything was shipped out to a lookalike domain, coder-infra[.]com, designed to blend in with real Coder traffic.
In practice, that grab-bag is enough to pivot into a company's AWS account, its GitHub, its production servers, and whatever AI tooling the team was wired into.
Timeline and fixed versions
| Item | Detail |
|---|---|
| Malicious delivery window | 07:35 to 21:45 UTC, August 31 |
| Exfiltration domain | coder-infra[.]com |
| Patched versions | 2.37.0, 2.36.4, 2.35.7, 2.34.9 |
| Customer data held by Coder | No evidence of impact |
What should affected teams do now?
Rotate everything the stealer could have grabbed, and do it before upgrading. That means cloud keys, CI/CD tokens, SSH keys, OIDC tokens, and any secrets a provisioner would have seen. Coder is telling admins to check firewall, proxy, DNS and VPC flow logs for any outbound connection to coder-infra[.]com, then hunt through provisioner logs for data.external.telemetry calls made during the 14-hour window. Coder has published a SQL query to help identify cached modules and template versions that came from the poisoned pool.
The honest bit in Coder's writeup: because the attacker's servers were never theirs, they do not have the logs. They cannot tell every customer whether they were hit. Each affected org has to work that out locally.
The uncomfortable part
The failure mode here is not a bug in Terraform, or in Cloudflare, or even really in Coder's application code. Someone got into the account that controls where traffic goes. Once you own the DNS and load-balancer layer of a package registry, you own everyone who trusts it. This is the same shape of problem as a compromised npm or PyPI mirror, just executed at the delivery layer instead of the package-upload layer.
One thing the post-mortem will say: registry infrastructure needs the same identity hardening, phishing-resistant MFA, and change alerting as production itself. Assume anything less and someone will walk in the front door of your CDN.
Rotate the keys. Read the flow logs. Trust the registry a little less tomorrow than you did last week.
