Coder registry compromise distributed malicious Terraform modules via Cloudflare

What happened

Coder, the company behind a platform that provisions remote development environments with Terraform, has disclosed a critical compromise of the registry that serves modules for its templates. According to a BleepingComputer report published on September 3, 2026 and summarized on dev.to, an attacker gained permission to modify Coder's Cloudflare configuration and added malicious IP addresses to the pool of servers delivering content for registry.coder.com. Some requests for modules were then forwarded to an attacker-controlled server, which responded with Terraform modules containing malicious code. Coder tracks the issue in security advisory GHSA-vx42-ghc9-gw65. How the attacker initially obtained the Cloudflare access remains unconfirmed.

How the attack worked

The intrusion played out entirely on the distribution side, which is what makes it notable. After adding the malicious endpoint to the Cloudflare pool, the attacker never needed to connect to a victim environment. Instead, victims' provisioners fetched the tampered modules through a channel they already trusted, and the malicious code executed as part of routine template imports, template updates, dry runs, or workspace builds. To an operator, the process would have looked like an ordinary workspace creation or template update.

Once running, the malicious code searched the execution environment for credentials and attempted to send what it found to coder-infra[.]com. Whether transmission actually succeeded has to be verified separately in each environment. Two factors complicate triage: legitimate modules were still delivered to some users during the same window, so fetch timestamps alone cannot show whether a given environment received a poisoned module, and caching means a stored malicious module could execute after the distribution window closed.

What the malicious code could reach

Per Coder's explanation, the exposure depends on where and when the module ran:

• Secrets available to the provisioner, including environment variables, configuration files, and terminal command history, were potential targets in every scenario.
• During template import, update, or dry run, user secrets are not passed in, so only the provisioner's own information was at risk.
• During a workspace build, the user's OIDC token, configured SSH keys, and external authentication tokens for the target template were additionally exposed. External authentication refresh tokens were not included.
• Where the provisioner runs within the same service as coderd, Coder configuration information such as database passwords and external authentication settings may also have been exposed.

Indicators and detection

Coder's advisory names several observables for investigators:

• Provisioner job logs, specifically provisioner_job_logs.output, may contain the string data.external.telemetry, and the advisory supplies SQL queries to search for it.
• DNS, proxy, or HTTP logs may show queries or connections to coder-infra[.]com or www[.]coder-infra[.]com, including HTTP requests to /cli/check. Coder stresses that seeing queries or connections alone does not prove credential exfiltration succeeded.
• Modules fetched during the window, along with referencing template versions and workspace build jobs, can remain in Coder's stored data for review, though a fetch record does not confirm a module was malicious.
• If stolen credentials were later reused, unusual source IPs or operations may surface in cloud, CI/CD, or AI API audit logs.

Teams scoping impact should examine outbound traffic up to the last use of any affected cache, not just the distribution window itself.

What to do

The guidance is to determine whether targeted modules were fetched and executed, delete affected module caches, re-fetch verified distribution packages, and rotate any secrets that were reachable from the execution environment. Updating to the patched version of Coder is recommended, but Coder cautions that an update alone should not be treated as proof of no impact. Longer term, restricting provisioner privileges, relying on short-lived credentials, and enforcing outbound allowlists would have constrained both what the malicious code could read and where it could send data.

Why it matters

This is a supply-chain compromise of a trusted channel rather than a direct breach of customer infrastructure. The attacker tampered with delivery infrastructure at the CDN layer, and the target's own provisioners then executed the payload during operations that look identical to normal activity. Caching extends the risk window beyond the registry fix, and because legitimate and malicious modules were served simultaneously, standard fetch logs are not enough to scope the blast radius. For teams running Terraform at scale, it is a concrete reminder that registries, and the CDN fronts in front of them, sit inside the trust boundary for infrastructure code, and that credentials handed to provisioners should be assumed reachable by any module those provisioners fetch.