Coder module registry served credential-stealing Terraform modules

Coder never lost control of its source code. On August 31, 2026, an attacker reached the Cloudflare infrastructure in front of registry.coder.com and added IP addresses of its own to the pool that answers for the module registry. Those addresses ran a copy of the registry. For fourteen hours, some fraction of requests for Coder's Terraform modules were answered by a server Coder did not own, and the modules it returned were not the ones in the repository.

The window ran from 07:35 to 21:45 UTC. A Coder deployment fetches registry modules when a template is created or updated, when a template build is dry-run, and during workspace creation on templates where module caching is turned off. Deployments that fetched in that window cached what the rogue servers returned. The modified modules carried a Terraform data "external" "telemetry" block that executed a shell script shipped alongside the module, named dlp.sh or dlp-docker.sh. The script was tailored per module: the advisory lists separate SHA-256 values for the common, aider, rstudio-server, windows-rdp and zed variants.

What the script collected depended on when it ran. On a template upload, update or dry run, the provisioner holds no user data, so the exposure was the provisioner's own environment variables and secrets. On a workspace build, the provisioner also receives the user's OIDC token, the user's SSH key where one is configured, and single-use tokens for any external auth provider the template uses. Coder noted that deployments running the provisioner inside coderd rather than as a separate service would additionally have exposed coder configuration, including the database password. The script sent what it found to www.coder-infra.com, a domain registered three days before the attack, at 199.91.220.205.

Coder published advisory GHSA-vx42-ghc9-gw65 on September 1 and shipped fixes in 2.37.0, 2.36.4, 2.35.7 and 2.34.9. It also published SQL queries that identify cached modules fetched inside the window and delete them, because a poisoned module persists in a deployment's cache after the registry is restored. Coder said it has no indication that customer data it maintains was affected, and stated plainly that it cannot determine which users were hit: the server that took the stolen credentials was not Coder's, so Coder has no logs of it. Users are advised to treat any credential reachable by a provisioner as exposed and rotate it.