Secretus logo
newscodersupply-chainterraform

Coder Registry Compromise: Rotate Secrets After the Trusted Download Path Fails

Coder confirmed its registry served malicious Terraform modules designed to steal cloud and CI/CD credentials. Scope exposure before rotating reachable secrets.

·9 min read·Secretus Editorial

Coder has confirmed that infrastructure supporting its official module registry was compromised and served malicious Terraform modules to a subset of users on August 31, 2026. The added code was designed to find and exfiltrate credentials accessible to Coder provisioners and workspaces. Potentially exposed material included cloud and AI-tooling API keys, CI/CD credentials, OIDC tokens, configured SSH keys, configuration secrets and, in some deployments, database passwords.

This was not a case where a user selected an obviously suspicious download domain. Coder says an unidentified actor added unauthorized servers to the Cloudflare infrastructure behind its real registry. Some legitimate registry requests were then routed to those servers. A trusted hostname therefore delivered an untrusted artifact.

What Coder has confirmed

Coder's security advisory defines the malicious delivery window as 07:35–21:45 UTC on August 31. Users may have been exposed when they created or updated a workspace template, ran a template-build dry run, or created a workspace that needed to download a registry module during that period. The exact conditions depend partly on module caching.

The malicious modules attempted to collect provisioner environment variables, cloud and AI API keys, CI/CD credentials, configuration-file secrets, terminal history, OIDC tokens, SSH keys and one-time external-authentication tokens. When a provisioner ran inside the main Coder service, its database password and other service configuration could also have been reachable.

Coder says refresh tokens were not passed to the provisioner and that it has no indication that customer data maintained directly by Coder was affected. Those limits should be preserved. They do not prove that every customer deployment was safe, and they do not establish how many secrets were successfully collected.

The blast radius is an execution question, not a version question

Version inventories alone cannot answer whether an organization was exposed. The attacker changed the delivery infrastructure, so the same requested module could be legitimate for one download and malicious for another. Coder also says it does not control the attacker's server logs and therefore cannot conclusively identify every affected deployment.

Start by reconstructing activity during the published window. Identify template imports, updates, dry runs and workspace builds that could have fetched a module. Review the SQL queries and indicators in Coder's advisory, correlate provisioner activity with DNS, proxy, firewall and VPC-flow telemetry, and preserve the results before clearing cached modules. Do not assume that installing a patched build retroactively removes credentials already copied elsewhere.

Contain first, then rotate by reachability

  1. Freeze the affected path. Stop new template imports and workspace builds that could reuse suspect cached artifacts until the registry content and local caches are verified.
  2. Identify executions. Use Coder's published queries and your own build, proxy and network records to find activity in the exposure window.
  3. Isolate suspect provisioners and workspaces. Preserve evidence before rebuilding or deleting them.
  4. Inventory reachable secrets. Include environment variables, CI/CD stores, cloud profiles, AI provider keys, SSH material, OIDC sessions, terminal history and service configuration.
  5. Revoke sessions before issuing replacements. Disable active tokens and old credentials so the attacker cannot use them while rotation is underway.
  6. Generate replacements on a known-clean system. Do not create or display the new value inside a workspace that may have executed the malicious module.
  7. Verify downstream use. Search cloud, source-control, registry and identity logs for activity performed with the old identities.

Protect the recovery channel from the compromised environment

Large rotations fail when teams paste replacement keys into the same tickets, terminals or chat histories that were accessible before containment. Establish a separate recovery channel with named owners, independent identity verification and a record of authorization that does not contain the secret itself.

Once the recipient and endpoint are verified, Secretus can deliver a replacement password, API key or recovery value through a time-limited one-time link instead of leaving plaintext in email or a persistent collaboration system. Use the shortest practical lifetime and a separately communicated context so the recipient knows what the value is for without the secret being copied into the audit trail.

A secure transfer channel cannot clean an infected provisioner, prove that the recipient's device is trustworthy or revoke an already stolen credential. The order matters: contain, scope, revoke, generate on a clean system, verify the recipient, deliver narrowly, then monitor use.

What remains unknown

Public reporting does not establish how the actor obtained access to the Coder-controlled Cloudflare configuration, how many registry requests reached the unauthorized servers, how many modules executed, or which organizations lost usable credentials. BleepingComputer and other outlets independently reported the disclosure, but their central technical facts derive from Coder's investigation rather than a separate forensic examination.

Sources