Coder Registry Compromised: Malicious Terraform Modules Stole Cloud Credentials and AI Tokens

Requests Redirected to Attacker-Controlled Servers

The infrastructure associated with registry.coder.com, Coder’s primary module registry, was compromised and used to distribute tampered Terraform packages. The incident is classified as Critical, with a CVSS v4 score of 9.0 out of 10.

An unidentified threat actor gained access to Coder’s Cloudflare infrastructure and added unauthorized IP addresses to the pool of servers associated with the registry. As a result, Cloudflare routed some user requests to attacker-controlled systems instead of legitimate servers.

The hostile systems replicated the registry’s behavior and served artifacts containing malicious code. Not every request necessarily reached the counterfeit infrastructure: distribution depended on traffic balancing across the addresses in the pool.

The exposure window ran from 07:35 UTC to 21:45 UTC on August 31, 2026. The security advisory, published on September 1, 2026, under the title “Malicious Packages Served from Unauthorized Registry Server,” states that any deployment that retrieved a module during those hours must be considered potentially exposed.

The compromise affected a sensitive component of the software supply chain. Coder is used to provide secure, self-hosted cloud development environments, including environments for building and deploying artificial intelligence applications. Organizations listed as users of the platform include Dropbox, Palantir, Square, Mercedes-Benz, KKR, EnBW, the U.S. government, and defense companies. It is not known which customers actually received the tampered modules.

The Stealer Hidden in the Terraform Modules

The malicious packages acted as an information stealer within the environment where the provisioner executed Terraform code. Their goal was to collect credentials and configuration data that could be used to access cloud infrastructure, development pipelines, and external services.

The code searched for, among other items:

• environment variables and secrets available on the provisioner;
• cloud provider API keys;
• API keys for artificial intelligence tools;
• CI/CD credentials;
• secrets stored in configuration files;
• terminal history;
• users’ OIDC tokens;
• configured SSH keys;
• one-time tokens for external authentication providers;
• the Coder database password;
• configuration data accessible when the provisioner ran inside coderd.

The collected information was sent to coder-infra[.]com, a domain chosen to resemble Coder’s legitimate infrastructure. The address listed in the advisory is www[.]coder-infra[.]com, which was reportedly registered on August 28, 2026.

The amount of data accessible to the malware varied depending on the operation being performed. When a template was loaded, updated, or dry-run, the provisioner did not receive the user’s secrets or personal information. However, values already present on the provisioner remained exposed, including environment variables and local credentials.

The risk increased while building a workspace. In that scenario, the provisioner could receive the user’s OIDC token, the corresponding SSH key if configured, and tokens for external providers enabled for that template. These were one-time tokens; according to Coder, refresh tokens were not transmitted.

If the provisioner operated inside coderd, the malicious code could also access the database password and other sensitive platform settings. The compromise could therefore extend beyond a single workspace.

Exposed Deployments and Versions

All Coder versions earlier than 2.37.0 are affected. Fixed releases are:

• 2.37.0
• 2.36.4
• 2.35.7
• 2.34.9

Organizations can upgrade to the latest version or to the fixed release in the supported branch they currently use. The incident has no CVE identifier.

A deployment may have been affected if it downloaded a module from registry.coder.com during the exposure window. This primarily occurs when creating a new template or a new version of an existing template.

Creating a workspace can also trigger a new download, particularly when module caching is disabled in the template settings. Caching is enabled by default. However, a workspace may have been built later using a template version in which the tampered module had already been cached.

This makes a software update alone insufficient. A malicious package left in the cache may continue to be used during new deployments even after the registry resumes serving legitimate content.

Coder reviewed the currently available template versions and declared them free of the malicious code. There are no indications that customer data stored directly by Coder was accessed. However, the investigation cannot be considered complete: the malicious servers were outside Coder’s control, and their logs are not fully available.

Indicators to Search for in Logs and Templates

Organizations should inspect DNS, firewall, proxy, and VPC flow logs for outbound connections to the exfiltration domain. The primary network indicators are:

• domain: www[.]coder-infra[.]com;
• IP address: 199.91.220[.]205;
• URL: http://www[.]coder-infra[.]com/cli/check;
• HTTP header: X-CLI-Token: your-secret-token.

Terraform files should be checked for a data "external" "telemetry" block that executes ${path.module}/dlp-docker.sh. In provisioner job logs, the most useful detection string is:

data.external.telemetry

The SHA-256 hashes of the reported files are:

File	SHA-256
dlp-docker.sh	7190a17c593276d7fd71c4863a4bc0b6c957ed14249288e6f64c5540e2c49398
Common dlp.sh	a7f4fa5f7e33b2a6f6488cf28444584caa449144d246b083de919162f5514247
dlp.sh for Aider	414d01f6072fbf05bef513e277f4c2b504a413c8e2aa5bae133a5cbc0cda9dc1
dlp.sh for RStudio Server	a64ce3038f2a501c9735abf6a1f9f04cbddbad53371cd68bec0f7510365c8ffa
dlp.sh for Windows RDP	ebbe0d2ed8cfaf9e19edb38ce44d6b407f9771b5c0813a7add27c05f66e89596
dlp.sh for Zed	7ef6b8c3c976fb60b3fa22e9e294ba548d9b532e060c1323a0124a3a7a647f13

The absence of these hashes does not automatically rule out exposure. Time-based checks on downloaded modules and the workspaces that used them are still required.

How to Identify and Remove Modules from the Cache

Coder prepared SQL queries to identify module files created during the incident window. The criteria include the null identifier 00000000-0000-0000-0000-000000000000, the MIME type application/x-tar, and a creation time from 2026-08-31 07:35:00+00 inclusive to 2026-08-31 21:45:00+00 exclusive.

The queries join the files, Terraform values, template versions, and templates tables. They retrieve the template name and version, module ID, cache timestamp, and workspaces that used the component.

A separate query, named SearchLogsForKeyPhrase, searches provisioner logs for data.external.telemetry. Results include the job, build, workspace, template, owner or initiator, status, and start time.

Suspicious modules must be deleted before the templates are deployed again. The official procedure creates a temporary table containing the identified IDs, clears the cached_module_files references, deletes the files from the files table, and performs all operations within a BEGIN/COMMIT transaction.

Patching and Credential Rotation

The response should follow a specific order: identify the affected modules, delete them from the cache, and upgrade Coder to 2.37.0, 2.36.4, 2.35.7, or 2.34.9. Coder was also preparing a subsequent release with automated remediation procedures.

All credentials potentially accessible to provisioners should be proactively rotated. Priority should be given to cloud keys, AI service tokens, CI/CD credentials, secrets in environment variables, SSH keys, OIDC tokens, and the Coder database password.

Credentials stored in configuration files or shell history must also be considered. The inability to prove exfiltration does not rule it out: the lack of complete logs from the hostile servers prevents a conclusive assessment for every deployment.