# Coder's Cloudflare Infrastructure Was Hijacked to Deliver Credential-Stealing Terraform Modules


When you run terraform init, your machine reaches out and trusts. It pulls modules from registries, executes provider code, and in doing so, briefly holds the keys to your entire cloud kingdom. Attackers who compromised Coder's infrastructure this week understood that better than most defenders did.


The attack hit Coder — the company behind open-source cloud development environments — at the Cloudflare layer. Attackers gained access to Coder's Cloudflare infrastructure and inserted unauthorized registry servers into the module resolution chain. Anyone whose Terraform workflow pointed at Coder's registry during the compromise window may have pulled malicious modules rigged to steal credentials.


## How the Module Poisoning Actually Worked


The mechanics here matter, because this isn't a "random package on a public registry" story. This was targeted infrastructure manipulation at the DNS and routing layer.


Cloudflare sits between Coder's users and Coder's backend infrastructure. By compromising Coder's Cloudflare account — almost certainly via stolen API token or account credentials — attackers could redirect registry traffic to servers they controlled without touching a single line of Coder's actual source code. The legitimate domain, the legitimate TLS certificate, the legitimate everything — all pointing at malicious infrastructure.


The payload: Terraform modules laced with credential-harvesting code. Terraform modules are not passive config files. When Terraform executes a module during init or plan, it can call provisioners, run scripts, and interact with providers — all of which happen in an environment that's typically loaded with high-privilege cloud credentials. AWS access keys, GCP service account tokens, Azure client secrets. The environment Terraform runs in is often the most privileged environment in an organization's entire CI/CD pipeline.


Stealing credentials from that context is the equivalent of picking someone's pocket while they're actively signing a lease on a building they own.


## The Blast Radius Nobody's Calculating


Here's what a lot of the initial coverage is glossing over: the forensic problem this creates is genuinely hard.


Terraform state files record *what* was provisioned, not *who accessed credentials during provisioning*. If malicious code ran during terraform init — before any infrastructure changes were made — it may leave no trace in state files at all. The attack could have been entirely pre-state: pull the module, execute the stealer, exit cleanly, and Terraform continues as if nothing happened.


That means affected organizations cannot simply audit their Terraform state to determine exposure. They need to:


  • Identify every pipeline, local machine, and CI runner that executed terraform init or terraform get against Coder's registry during the compromise window
  • Assume any cloud credentials present in those environments are compromised
  • Rotate aggressively: AWS IAM keys, GCP service accounts, Azure service principals, and anything else those environments touched

  • The rotation scope will be brutal for organizations running platform engineering teams on Coder. These aren't developer laptops with minimal permissions. These are the accounts that provision production VPCs, RDS instances, and IAM roles. An attacker sitting on those credentials doesn't steal data immediately — they establish persistence, enumerate permissions, and move when the moment is right.


    ## This Attack Fit Cloudflare Because Cloudflare Is Trusted


    The Codecov breach in 2021 used a similar playbook: compromise an upstream dependency in the CI pipeline, steal credentials at the moment they're most exposed. The attackers in that case modified a bash uploader script that hundreds of companies pulled automatically. The result was credential theft across a staggering range of enterprises.


    This Coder attack is Codecov-adjacent but technically more sophisticated. Codecov's attackers modified a file in a GitHub repository — detectable via hash verification. Coder's attackers compromised Cloudflare infrastructure itself, meaning the legitimate domain resolved to their servers. Hash checks on individual files wouldn't catch this. TLS verification wouldn't catch this. The trust model was the attack surface.


    That's an important pattern: as organizations harden their software supply chains with SLSA, sigstore, and artifact signing, attackers are shifting their focus upstream — to the infrastructure that hosts registries rather than the packages themselves. You can sign every module in your registry. If attackers control the DNS resolution, they can serve their own signed garbage instead.


    Cloudflare API token hygiene is criminally underappreciated as a security control. A token with zone-level DNS write access or Workers deploy access is functionally equivalent to domain control. If that token is stored in a CI system, shared across teams, or issued without expiration, it's a ticking problem.


    ## What Defenders Should Do Right Now


    If your organization uses Coder, or uses any Terraform module registry that proxies through a third-party CDN:


    Immediate:

  • Identify all terraform init runs against affected registries during the compromise window (check CI logs, runner logs, developer machines)
  • Rotate all cloud credentials from any environment that ran Terraform during that window — treat it as confirmed compromise, not suspected
  • Check cloud provider audit logs for unusual API activity from those credential sets in the days following any affected runs

  • Structural:

  • Audit your Cloudflare API token inventory. Token permissions should follow least privilege. Zone-level DNS edit access should not be the same token you use for cache purging.
  • Mirror critical Terraform modules to an internal registry you control. Public module registries — however reputable — are third-party infrastructure you're trusting at init time.
  • Add module hash pinning and integrity verification to your Terraform workflows. The required_providers version pinning is not enough; pin specific checksums where possible.

  • ---


    ## HackWire Analysis


    What this attack reveals is a maturation in supply chain thinking that defenders haven't fully caught up with.


    The developer tooling ecosystem has spent the last three years reckoning with package-level supply chain attacks — malicious npm packages, typosquatted PyPI modules, compromised GitHub Actions. The response has been meaningful: artifact signing, SBOM requirements, dependency auditing. The security community has gotten better at asking "is this package what it claims to be?"


    The Coder attack asks a different question: "Is this server who it claims to be?" And the answer — because Cloudflare infrastructure was compromised, not a package — is that standard supply chain controls didn't help. You could have pinned your module versions, verified your checksums, and still pulled malicious code, because the registry itself was under attacker control.


    This is the next frontier of supply chain attacks, and it's underdefended. Platform engineering teams that manage internal developer platforms on tools like Coder tend to trust those tools implicitly — they're the infrastructure *beneath* the infrastructure. Security reviews of CDEs typically focus on the workloads developers run inside them, not on the integrity of the platform's own module resolution.


    The credential theft vector makes this especially high-consequence. Terraform isn't running as a developer's limited workstation user. It's running as an infrastructure provisioner with god-mode cloud access. Any credential exfiltration from that context gives attackers an entry point that most organizations' detection tooling isn't tuned to catch — because cloud provider API activity from a legitimate provisioning pipeline looks exactly like legitimate provisioning activity.


    Expect copycat attacks. The Cloudflare-infrastructure vector is novel enough that it will be replicated.


    — HackWire Editorial


    ---


    ## Related Coverage


  • Read more in our [Breaches](https://www.hackwire.news/category/breaches) coverage
  • Cross-reference with [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)