Coder Registry Hijack Stole Dev API Keys for 14 Hours

Nothing in Coder's module registry was ever modified. That is the part worth sitting with. For roughly 14 hours on August 31, 2026, a slice of the traffic bound for registry.coder.com never reached Coder at all. Somebody holding a stolen Cloudflare API key had added their own IP addresses to the pool answering for that hostname. DNS resolved. TLS handshook. The Terraform modules that came back were not the ones Coder published.

Key Takeaways

• Coder disclosed that an unauthorized party used a compromised Cloudflare API key to add attacker controlled IP addresses to the pool serving registry.coder.com, routing part of the registry's traffic to servers Coder did not run, per Coder's own incident writeup.
• The delivery window ran from 07:35 UTC to 21:45 UTC on August 31, 2026, and during it those servers returned modified Terraform modules carrying credential stealing code, as reported by BleepingComputer.
• The modules swept provisioner secrets, cloud and AI tooling API keys, CI/CD credentials, configuration file secrets, terminal history, user OIDC tokens, SSH keys, external authentication tokens and, inside coderd, Coder database passwords.
• Exfiltration went to the lookalike domain coder-infra[.]com; Coder says refresh tokens were not exposed and found no evidence of impact to Coder maintained customer data.
• Coder 2.37.0, 2.36.4, 2.35.7 and 2.34.9 close the delivery path, but upgrading cannot invalidate a secret that already left.

What Exactly Was Compromised?

Coder's Cloudflare configuration, not Coder's registry content. An attacker with a valid Cloudflare API key edited the set of origin addresses behind registry.coder.com so that some requests resolved to infrastructure they controlled.

Read that as an operator and the shape of the problem changes. Coder's build pipeline was fine, and the published modules in Coder's registry repository remain fine. What broke was the mapping between a name your tooling trusts and the machine answering to it, and that mapping lived in a third party dashboard behind an API key.

Coder has not said how that key was obtained, and concedes it cannot enumerate every affected deployment: the request logs proving who pulled what sit on servers the attacker owns. So "we were not notified" is evidence of nothing.

Why Didn't Module Integrity Checks Catch It?

Because Terraform does not checksum modules. It checksums providers, and only providers.

HashiCorp is explicit about this in the dependency lock file documentation: "At present, the dependency lock file tracks only provider dependencies. Terraform does not remember version selections for remote modules, and so Terraform will always select the newest available module version that meets the specified version constraints." No entry in .terraform.lock.hcl describes a module. No SHA-256 gets compared. There is nothing to fail.

So the attack needed no signing key, no maintainer account and no typosquat. A pinned version constraint would not have helped either, because the pin controls which version is requested, not which server answers. That is the structural break from the compromises we have covered all year: the arrayref crate that shipped an infostealer through crates.io and the Mastra npm packages backdoored by Sapphire Sleet both required the attacker to publish something. Here, publishing was optional.

What Did the Modules Actually Steal?

Everything a Terraform provisioner can see, which in a cloud development environment is close to everything.

Coder's advisory splits the blast radius by operation. Template operations target the provisioner's own secrets. Workspace builds add the user's OIDC tokens on top. When the provisioner runs inside coderd, the reach extends to database passwords and configuration secrets for the Coder deployment itself, per the inventory reported by eSecurity Planet.

Terminal history deserves a second look. It is not a credential store, but it is where people paste one anyway: a token on a curl command, a password in a connection string.

What Does a 14 Hour Window Mean for a CI Fleet?

More exposure than the number suggests, because 07:35 to 21:45 UTC covers the entire European working day and most of the American one.

Do the arithmetic on your own pipeline. A team whose CI runs terraform init on every push is not measuring one fetch. Fourteen hours at a build every ten minutes is 84 chances to hit an attacker origin, and because only part of the IP pool was poisoned, each fetch was an independent roll.

That intermittency is why nothing external will flag this for you. No CVE is attached to a hijacked IP pool, so no scanner fires and no dependency bot opens a pull request. This is the pattern IBM's Cost of a Data Breach Report keeps measuring: supply chain compromises take longer to identify and contain than any other breach vector, because the victim's own telemetry never showed anything wrong.

Where This Lands on Your Identity Provider

Cloud keys get the headline, but OIDC tokens and SSH keys are the pieces that reach a person rather than a project.

An OIDC token is issued by an identity provider, and in most engineering organizations that provider is also the login for the corporate mailbox, the code host and the ticketing system. Coder says refresh tokens were not exposed, which limits how long a stolen access token stays useful. That reassurance does not extend to SSH keys, which never expire unless somebody revokes them.

From a stolen SSH key to a code host account, and from there to the email address that recovers it, is a short and well travelled path. We watched a variation of it in the LastPass and Klue supply chain breach, where credentials taken from one vendor's build environment became the front door to accounts nobody had connected to it.

Your Rotation and Detection Checklist

Treat patching, hunting and rotating as three separate tasks, and do not let the first convince you the other two are done. Coder's security advisory GHSA-vx42-ghc9-gw65 carries the vendor specific steps.

• Upgrade and clear caches. Move to 2.37.0, 2.36.4, 2.35.7 or 2.34.9, then delete cached module artifacts so a tampered copy is not replayed from local disk.
• Grep every egress log for coder-infra[.]com. Firewall, proxy, DNS resolver and VPC flow logs across August 31 and the surrounding week. One hit turns this from precautionary into confirmed.
• Rotate cloud credentials first. AWS, GCP and Azure keys reachable from any provisioner, plus anything scoped through a CI role. Rotate rather than audit: the logs that would tell you which keys were read do not exist on your side.
• Rotate AI tooling and CI/CD secrets. Model provider API keys are metered and expensive to abuse quietly. Treat pipeline tokens, registry credentials and deploy keys the same way.
• Revoke SSH keys and force OIDC reauthentication. Reissue keys on code hosts and bastions, then invalidate active sessions at the identity provider instead of waiting for tokens to age out.
• Rotate coderd database passwords and configuration secrets if any provisioner ran alongside the control plane.
• Pin providers with signed checksums going forward. terraform providers lock populates verifiable hashes across your target platforms, and HashiCorp's Terraform security practices covers the surrounding controls. Modules stay unverified, so vendor the ones that matter into a repository you control.

What to Watch Next

Most of the coverage framed this as malicious modules being pushed to a registry. Nothing was pushed. That framing points defenders at package provenance, the layer that worked, and away from the layer that failed.

The interesting question is how many other developer tools resolve a trusted hostname with no integrity check underneath. Terraform modules are one answer. So are container image tags without digest pinning, shell installers piped from a URL and Helm charts pulled without provenance verification. Signing infrastructure such as Sigstore exists to make the artifact vouch for itself rather than the transport, and Terraform module adoption of it is close to nonexistent.

Verizon's 2025 Data Breach Investigations Report found third party involvement in 30 percent of breaches, double the previous year's share. Two things to watch: whether Coder explains how the Cloudflare API key was taken, and whether a harvested credential surfaces in a downstream intrusion at one of the large enterprises running the platform. The second usually lands months after everyone stopped reading about the first.