On September 4, 2026, Coder described an incident that took place on August 31 in its module registry. A compromised Cloudflare API key allowed an unidentified actor to add servers to the path serving registry.coder.com. Between 07:35 and 21:45 UTC, some downloads received modified modules designed to search for and exfiltrate credentials. On September 29, Coder said Coalition Incident Response had confirmed the scope and validated its response. Coder said the summary of this independent review could be requested from September 30; the public blog post does not reproduce it.
A legitimate domain, altered delivery
The key point is not a fake domain selected by a user. Coder says requests to the normal registry could be redirected to a malicious server. Terraform modules run in a provisioning chain, so they can see variables, tokens and files available to the provisioner.
Coder says its codebase and Google Cloud infrastructure were not compromised. That does not reduce the risk to a deployment that downloaded a module during the stated window to zero.
Scope depends on usage
Coder says to check template creation or updates, template build dry runs and workspaces built on a cluster where Terraform module caching was disabled. Caching is enabled by default. The advisory describes two possible access contexts: template builds exposed secrets available in the provisioner environment; workspace builds could also expose a single-use OIDC token, a configured SSH key and certain external authentication tokens. The OIDC tokens involved were not refresh tokens.
These facts do not show that every installation exfiltrated secrets. They do require a focused review of deployments that downloaded modules during the August 31 window.
The checks to run
List templates, template versions, template build dry runs and workspaces created during the August 31 window. Search for outbound connections to coder-infra.com, the lookalike domain named in the advisory, and the string data.external.telemetry in provisioner logs. Use the SQL queries and indicators in Coder’s GitHub advisory; also review firewall, DNS, proxy and VPC logs and module caches.
Update Coder to at least 2.37.0, 2.36.4, 2.35.7 or 2.34.9, depending on your branch. Purge suspicious modules from the cache before any new deployment, then rebuild templates after review. Preserve useful copies and hashes for investigation instead of overwriting them during cleanup.
Secret rotation is the priority
Rotate cloud keys, CI/CD credentials, AI-tool credentials and variables visible to affected provisioners. If a workspace build ran during the window, include the corresponding single-use OIDC tokens, configured SSH keys and external authentication tokens. Start with accounts that can change infrastructure or recover other access, and include secrets reused across environments. For shared accounts and rotation rules, see our team password-sharing guide and SMB password policy guide.
A version change does not revoke a token that was already read. If an indicator appears, isolate the workspace or provisioner, preserve logs and involve incident response.
The Soclyde connection
Soclyde does not control Coder Registry and cannot certify that a module was intact. It can help a team generate unique secrets and keep an inventory of access to rotate in local-first encrypted vaults, without multiplying copies in configuration files.
That organisation supports rotation after analysis, but does not replace Coder remediation, cache review or outbound-traffic monitoring.
Key takeaways
The Coder incident shows that a download from an expected domain can still come from altered infrastructure. Identify modules fetched on August 31, check indicators, fix Coder and revoke reachable secrets. To structure the rotation, read the secure password generator guide or contact Soclyde.
