Malicious Terraform modules served from Coder’s compromised Cloudflare infrastructure
On August 31, 2026, between 07:35 and 21:45 UTC, an attacker compromised a Coder Cloudflare API key and redirected part of the module registry’s traffic to a malicious server that exfiltrated cloud credentials. Check your logs for coder-infra[.]com and rotate the affected secrets.
August 31, 2026. Between 07:35 and 21:45 UTC, an attacker serves malicious Terraform modules from Coder’s registry. September 3, 2026. BleepingComputer breaks the story. September 4, 2026. Coder publishes its official advisory. The striking point: the registry itself was not “hacked” — the Cloudflare infrastructure was compromised. Why it matters: modules you downloaded from a “trusted” source were less trusted than they looked.
Bypassing the registry through the infrastructure
The registry.coder.com registry hosts the Terraform modules developers use to build their workspace templates. It is served behind Cloudflare. On August 31, an unauthorized actor compromised a Cloudflare API key and used it to redirect a portion of the registry’s traffic to a server they controlled.
The direct consequence: during the exposure window, a share of requests was served by the attacker’s server, which returned tampered versions of the modules. Those modules were designed to scan for and exfiltrate cloud credentials — AWS, GCP, Azure, and others — to the lookalike domain coder-infra[.]com. Coder states that its own source code and Google Cloud infrastructure were not compromised.
The platform’s footprint gives the risk its scale. Coder provides self-hosted cloud development environments used by organizations including Dropbox, Palantir, Square, Mercedes-Benz, and KKR, as well as public-sector and defense companies. A compromised provisioner inside one of those organizations is potentially a direct path to their infrastructure.
What the modules stole
Keep the headline before the detail: these modules were not trying to break anything but to steal — quietly, without disturbing the workspace itself. A well-built info stealer runs, copies what it finds, and leaves no visible trace.
The tampered modules acted as information stealers. Once executed on a host, they searched for, according to BleepingComputer:
- provisioner environment variables and secrets;
- cloud infrastructure and AI tooling API keys;
- CI/CD credentials;
- configuration-file secrets and terminal history;
- user OIDC tokens;
- configured SSH keys;
- one-time external authentication tokens;
- Coder database passwords when the provisioner ran inside
coderd.
The target is revealing: a Coder provisioner is, by construction, a machine that touches infrastructure. Compromising it means getting hold of the keys to the kingdom — those that grant access to the cloud, to CI/CD, and to development environments.
Coder’s response and the patched releases
Coder says it identified and remediated the incident the same day: the malicious IPs were removed, the cache purged, and registry.coder.com is confirmed clean. But the window lasted fourteen hours, and since the attacker’s infrastructure sits outside its control, Coder admits it cannot conclusively identify every compromised deployment.
The patched releases are 2.37.0, 2.36.4, 2.35.7, and 2.34.9. Coder recommends upgrading to the latest version, which includes automatic remediation steps, and provides SQL queries to identify affected cached modules and template versions. The top advice: inspect firewall, proxy, DNS, and VPC flow logs for any outbound traffic to coder-infra[.]com.
# look for connections to the attacker's domain in flow logs
grep -R "coder-infra.com" /var/log/ 2>/dev/null
# list cached modules that may have been pulled during the window
coder templates list 2>/dev/nullCoder also notes that refresh tokens were not passed to the provisioner and that no customer data it maintains appears to have been touched. A reasonable caution: most of the stolen secrets were taken from customer hosts, not from Coder’s own systems.
What this says about the 2026 supply chain
This attack is not the classic “malicious npm package.” The attacker did not push code into a repository: they compromised the delivery infrastructure — the pipe through which trusted code flows. That is a step change. Trusting “the official registry” becomes conditional, because the registry itself depends on a chain of third-party infrastructure.
The pattern joins a trend documented over recent months: the BGP hijack that served a tampered Virtualizor update, or the 77 malicious extensions published on Coder’s Open VSX marketplace this summer. The common thread: the supply chain no longer stops at source code — it now spans the network, DNS, CDNs, and the API keys of intermediary platforms.
Locking down your module consumption
The Coder incident forces a practical conclusion: a registry, even an official one, is one trust boundary among many. The defense that survives the compromise of a whole registry comes down to three moves.
Pin and verify. Lock the versions of your Terraform modules and record their checksums in your repository. A module whose checksum changes without your intent is a module you must not run.
Route through a private mirror. Consuming public modules through an internal registry you control shrinks the surface: you audit what enters, and you cut direct access to public registries from your pipelines.
Verify provenance. For sensitive modules, require signatures or signed artifacts, and review the API-key permissions of your intermediary platforms (CDN, DNS, registry) — that is exactly where Coder was hit.
Recall the scale of the risk: the window lasted fourteen hours, a full working day across several time zones. Plenty of organizations could have provisioned “trusted” modules without suspecting they came from a server the attacker controlled. And because the Coder provisioner touches infrastructure by construction, every tampered module was a potential entry ticket into a victim’s cloud and CI/CD.
Those moves do not replace vigilance: they make it possible, by giving your teams a way to detect tampering rather than endure it.
What this changes for operators
The shift is philosophical: a decade ago, the supply chain question was mostly about source code — who wrote what, who merged what. In 2026, it is about infrastructure — who serves which binary, through which CDN, with which API key. Coder’s registry was not compromised by a flaw in its code but by a key held by a trusted third party.
The governance lesson follows: the compromised key belonged to a supplier — Cloudflare — used by Coder. An organization is only as safe as the weakest third party it relies on; auditing your own systems is no longer enough, you must also review the API keys and access of your providers.
For responders, one detail matters: Coder published SQL queries to find affected cached modules and recommends searching provisioner logs for data.external.telemetry. If you cannot prove a module was pulled outside the window, treat it as suspect and rotate its dependent secrets anyway. The cost of a wrong rotation is an hour of reconfiguration; the cost of a missed one is a cloud account.
None of this is specific to Coder: every registry served through a third-party CDN inherits this same risk surface, and every team consuming public modules should assume that surface will be tested. The response is not to abandon registries, but to stop treating them as fixed anchors of trust.
Verdict
If you use Coder workspace templates, upgrade to a patched release (2.37.0, 2.36.4, 2.35.7, or 2.34.9) and audit your logs for coder-infra[.]com.
If you provisioned modules during the August 31 window, immediately rotate the affected secrets — cloud API keys, OIDC tokens, SSH keys, CI/CD credentials — without waiting for the audit to finish.
If you consume public Terraform modules, pin versions and lock them by checksum: that is the only defense that survives the compromise of an entire registry.