Attackers needed no counterfeit website to slip malicious Terraform modules to developers. Unknown intruders gained access to the Cloudflare infrastructure that Coder relies upon. They added their own IP addresses to the pool of the official registry.coder.com. Consequently, they compelled the genuine domain to intermittently serve modified packages bearing a secret-stealer.
The attack persisted for roughly 14 hours on August 31, from 07:35 to 21:45 UTC. A portion of the requests to the official registry landed on the attackers’ servers. There, an altered copy of the Coder Registry resided. As a result, a developer could address the correct registry.coder.com and nonetheless receive a malicious Terraform module. Neither a simple domain check nor permitting downloads solely from the trusted address offered protection against such a scheme.
How the Secret-Stealer Operated
The malicious code executed through a Terraform data “external” “telemetry” block and the scripts dlp.sh and dlp-docker.sh. The thief hunted for secrets in environment variables, configuration files, and terminal history. Imperiled were cloud-infrastructure and AI-service keys, CI/CD credentials, SSH keys, OIDC tokens, and other data accessible to Coder’s components.
When an infected module ran during a workspace build, the risk grew even greater. The provisioner could obtain the user’s OIDC token, the configured SSH key, and single-use tokens from external authentication services. If the provisioner was operating inside coderd, the malicious code could potentially glimpse the database password. Furthermore, it could see other parameters of Coder itself. The harvested information was dispatched to coder-infra[.]com, a domain resembling the developer’s own infrastructure. That domain was registered on August 28, three days before the attack.
Who May Have Been Affected
Under suspicion fall organizations that, during the perilous window, created new templates, updated their versions, ran a trial build, or deployed workspaces without caching Terraform modules. Caching is enabled by default. Therefore, previously saved, safe copies may have spared a portion of installations.
Coder cannot precisely identify all those affected. The malicious servers belonged to the attackers, so the company holds none of their logs. As the official security advisory details, administrators are advised to inspect DNS, firewalls, proxies, and VPC logs for connections to coder-infra[.]com. They are also advised to search the provisioner logs for the string data.external.telemetry, to remove suspicious modules from the cache, and to rotate all secrets the provisioner may have accessed.
A Critical Rating and the Supply-Chain Lesson
The company assessed the incident as critical, with a CVSS rating of 9.0 out of 10. The corrected releases of Coder bear the numbers 2.37.0, 2.36.4, 2.35.7, and 2.34.9. No separate CVE was assigned to the incident. This is because it concerns not a classic software vulnerability, but a compromise of the component-distribution infrastructure.
Coder maintains that, as yet, there are no signs of access to the customer data the company itself stores. The attack, however, lays bare an unsettling feature of supply-chain compromise. A trusted domain and the correct registry address no longer guarantee that the component obtained from it truly came from the developer’s server.
Support Our Threat Intelligence
Find our threat intelligence and malware analysis helpful? Support our work today and unlock a 100% ad-free reading experience!