Coder Registry Compromise: Malicious Server Added to Cloudflare Pool to Distribute Malicious Terraform Modules

Posted on by — No Comments ↓

1. Overview

  • Article Title: Coder’s registry infrastructure compromised to push malicious modules
  • Source: BleepingComputer
  • Published Date: 2026-09-03
  • Original URL: BleepingComputer
  • Related Source: Coder security advisory GHSA-vx42-ghc9-gw65
  • Related Malware, Threat Groups, CVEs, Products: Malicious Terraform module, Coder, registry.coder.com, Cloudflare, Terraform
  • Severity: Critical
  • Review Update: Content reviewed on 2026-09-05. Updated details regarding malicious code functionality, confirmed exfiltration, secret exposure based on execution conditions, scope of post-distribution investigation, and provider explanations. Revised “Victim / Administrator Perspective” to describe events visible in screens, logs, and devices, along with their observation conditions.

2. Executive Summary

An attacker modified Coder’s Cloudflare configuration to redirect some registry requests to malicious Terraform modules. Organizations must investigate whether targeted modules were fetched and executed, clear affected caches, and rotate any secrets that were accessible from the execution environment.

3. Attack Flow

From Unauthorized Endpoint Addition to Malicious Module Execution

  1. An attacker gains access permissions to modify Coder’s Cloudflare configuration. The initial intrusion method is unconfirmed.
  2. Malicious IP addresses are added to the module registry’s delivery servers.
  3. Some registry requests are forwarded to the malicious server, distributing Terraform modules containing malicious code.
  4. The targeted Coder environment fetches the malicious module. If caching is enabled, stored modules might also be used at a later time.
  5. Malicious code may run within the provisioner during template import, update, dry run, or workspace build.
  6. The malicious code is designed to search for credentials available in the execution environment and send them to a server at coder-infra[.]com. Successful transmission in each environment must be verified separately.

4. Attacker Position and Execution Location

  • An external attacker who gained permissions to modify Coder’s Cloudflare configuration.
  • Without connecting directly to the victim environment, the attacker causes the victim’s provisioner to execute code obtained via a trusted registry.

5. Victim / Administrator Perspective

Victim

  • Inference: The process looks like a normal workspace creation or template update, making it difficult to recognize the execution of a malicious module.

Administrator

  • Provisioner job logs (provisioner_job_logs.output) may contain the string data.external.telemetry. The official Coder advisory also provides SQL queries to search for this string.
  • Inference: If DNS or proxies record network traffic, queries or HTTP/HTTPS connections to coder-infra[.]com or www[.]coder-infra[.]com may appear. HTTP requests may include /cli/check. Records of queries or connections alone do not prove successful credential exfiltration.
  • Inference: Modules fetched during the target time frame, along with referencing template versions and workspace build jobs, may remain in Coder’s stored data. Fetch timestamps alone do not confirm whether a module was malicious.
  • Inference: If credentials were later used for unauthorized activities, unusual source IPs or operations may appear in cloud, CI/CD, or AI API audit logs.

6. Conditions for Success and Failure

Success Conditions

  • Actually fetching a malicious module from registry.coder.com during the target time frame. Because legitimate modules were also distributed to some users, timestamps alone are inconclusive.
  • The malicious module executes during template import, update, dry run, or workspace build. Execution after the target time frame due to caching is also within the scope of investigation.
  • Credential theft requires the provisioner to read the target information and successfully transmit it externally.

Failure / Risk Reduction Conditions

  • Delete affected module caches and re-fetch verified distribution packages.
  • Check and delete caches, then update to the patched version of Coder. Do not rely solely on updates to confirm the absence of impact.
  • Inference: Limit impact by applying the principle of least privilege to provisioners, using short-lived credentials, and enforcing allowlists for outbound communications.

7. What Happens on Success

  • When the malicious module runs, secrets stored in the provisioner’s environment variables, configuration files, or terminal command history may be exposed.
  • During template import, update, or dry run, user secrets are not passed; only the provisioner’s own information is targeted. During workspace build, the user’s OIDC token, configured SSH keys, and external authentication tokens for the target template are additionally passed. External authentication refresh tokens are not included.
  • Coder explains that in configurations where the provisioner runs within the same service as coderd, Coder configuration information such as database passwords and external authentication settings may also have been exposed.
  • Inference: Unauthorized access to development and cloud environments via stolen credentials or re-execution of malicious code from lingering caches may occur.

8. Observable Logs

  • Email: None.
  • Proxy/SWG/DNS: Fetches from registry.coder.com, and DNS queries / HTTP/HTTPS traffic to coder-infra[.]com and www[.]coder-infra[.]com. Include HTTP /cli/check as noted in official IOCs. Queries and connections alone do not confirm successful exfiltration.
  • Endpoint/EDR: Inference: Verify access to environment variables, configuration files, and terminal command history by Terraform and provisioners, as well as the execution and external transmission of malicious scripts.
  • Identity/IdP: Inference: Check for unauthorized use and authentication results regarding potentially exposed OIDC tokens, SSH keys, and cloud/CI/CD credentials.
  • SaaS/Cloud (Customer Side): Coder template import, update, dry run, and workspace build logs, along with module contents and digests.
  • SaaS/Cloud (Provider Side): Cloudflare configuration change history. Customers typically cannot access these logs directly; treat them as part of the provider’s investigation information.
  • Network: Outbound DNS, HTTP, TLS, and VPC Flow Logs. Investigate not only fetches during the distribution window but also traffic until the final use of the affected cache.

9. Attack Success Assessment

The following criteria are used to investigate individual environments and do not imply that success at every stage was observed in a single article.

  • Attack Attempt Observed (Success Unconfirmed): Fetching from the legitimate registry during the target time frame only marks an environment as a potential candidate. Even if malicious module retrieval is confirmed, execution and successful information theft remain unconfirmed.
  • User Activity Confirmed: Confirmation of template import, update, dry run, or workspace build initiation. This alone does not confirm malicious module execution.
  • Initial Execution Confirmed: Confirmation of script execution or other actions started by the malicious module. Check processing details and execution results, not just the string data.external.telemetry.
  • Malware Execution or Authentication Success Confirmed: Verify credential discovery attempts by malicious code within provisioner execution logs. For subsequent authentication, separately confirm unauthorized authentication success by the attacker.
  • Data Exfiltration or Session Compromise Confirmed: Confirm external transmission of data including credentials, or session compromise via stolen tokens. DNS queries, connection attempts, or established connections alone do not confirm this stage.
  • Subsequent Compromise Confirmed: Confirm unauthorized operations or lateral movement in cloud, CI/CD, or AI environments using stolen credentials.

10. Investigation Playbook

Inference: Investigation recommendations based on article observations and functional descriptions.

  • Trigger: Module fetch during the target time frame, communication toward coder-infra[.]com, and logs containing data.external.telemetry.
  • Initial Verification: Preserve Coder version, templates, caches, module contents, workspace build history, and network logs. Use the official advisory’s SQL query to extract candidate targets, but do not determine exfiltration success based on the results alone.
  • Endpoint: Inspect provisioner processes, access to environment variables/files, command history, and caches. Verify derivative workspace build history and credentials used within them.
  • Authentication / Cloud: Determine whether operations involved template actions or workspace builds, and whether coderd was co-located. Narrow down exposure candidates across cloud, AI, CI/CD, OIDC, SSH, and DB to check usage history.
  • Subsequent Activity: Trace unauthorized resource creation, pipeline modifications, artifact publication, AI API usage, and SSH logins.
  • Containment: Preserve evidence, delete and re-fetch affected caches, and update Coder. Block communication to attacker destinations and preemptively rotate any credentials that were accessible within the execution environment.
  • Assessment Categorization: Distinguish between exposure candidates by time frame, malicious module retrieval/storage, execution, credential access, successful transmission, and subsequent unauthorized use.

11. Defense and Detection Ideas

Inference: Guidance for operational application. Do not confirm successful compromise based solely on individual logs or matching IOCs.

  • Single Event: Communications to coder-infra[.]com.
  • Single Event: Provisioner log entry data.external.telemetry. Use both as investigative clues that require checking content and execution results.
  • Chronological Correlation: Correlate registry fetch -> template operation / workspace build -> access to secrets -> external transmission -> unauthorized use of credentials.
  • Threat Hunting: Enumerate modules fetched between August 31, 07:35 and 21:45 UTC and derivative workspaces using official SQL queries and logs, tracking cache usage and external transmission even after distribution has ended.
  • Log Gaps: Without module contents/digests, provisioner execution records, and details on external transmission, it is difficult to distinguish between retrieval, execution, and successful exfiltration. Treat Cloudflare configuration changes as provider-side investigation data.
  • Priority Countermeasures: Implement cache deletion/re-fetching, patch application, and rotation of credentials accessible under the execution conditions as a single set of actions.

12. Facts / Inference / Hypothesis

Facts

  • Coder announced that an attacker accessed their Cloudflare infrastructure and added unauthorized IP addresses to the module registry’s delivery servers.
  • Some requests were forwarded to the malicious server, distributing Terraform modules containing malicious code.
  • The distribution window specified by Coder is August 31, 2026, from 07:35 to 21:45 UTC.
  • The malicious code was designed to search for credentials and transmit them to the attacker’s server. Organizations must individually verify whether retrieval, execution, or data exfiltration occurred.
  • Potentially exposed information varies by execution condition. Template operations target the provisioner’s own secrets, workspace builds additionally target user OIDC tokens, and co-located coderd configurations may also target database passwords.
  • Coder listed versions 2.37.0, 2.36.4, 2.35.7, and 2.34.9 as patched versions, recommending the deletion of affected caches and preemptive rotation of potentially exposed credentials.
  • Coder stated there is no information indicating an impact on customer data held by Coder. This statement does not mean customers’ own Coder environments are unaffected.
  • Because Coder does not manage the attacker’s servers and cannot identify affected users, they request organizations to conduct independent investigations.

Inference

  • Merely allowing TLS connections to legitimate domains cannot prevent malicious distributions when delivery configurations are compromised. The origin and digest of distribution packages must be verified using independently trusted information.
  • Environments created from templates that fetched the targeted module must also be investigated to track lingering and reused caches. Do not limit investigations solely to terminals that fetched the module or the distribution time frame.

Hypothesis

No additional hypotheses. Unverified items are recorded under “Open Questions / Additional Investigation.”

13. MITRE ATT&CK Mappings

  • T1195.002 Supply Chain Compromise: Compromise Software Supply Chain (High): Injection of a malicious Terraform module into a trusted registry delivery channel.
  • T1552.001 Unsecured Credentials: Credentials In Files (High): Corresponds to malicious code searching for secrets within configuration files and command history. Does not indicate successful theft in every environment.
  • T1041 Exfiltration Over C2 Channel (Medium): Candidate matching the functionality to send credentials to the attacker’s server. Successful transmission and use of communication channels as C2 in each environment must be verified separately.

14. Open Questions / Additional Investigation

  • Total number of organizations and environments that actually fetched and executed the malicious module, and the scope of successful credential theft.
  • Initial intrusion method used to gain Cloudflare configuration modification permissions.
  • Presence of any malicious modules or additional payloads other than those listed in the official advisory.

15. Impact on SOCs

Environments operating Coder that fetched modules from registry.coder.com during the target time frame are candidate targets. Identify fetched content, template versions, caches, and derivative workspaces. Extend the investigation of external transmissions to the final use of caches, and check HTTP traffic to coder-infra[.]com and www[.]coder-infra[.]com. Rotate credentials that were accessible based on the execution conditions.

16. Summary by Role

  • For SOCs: Evaluate module fetches, data.external.telemetry, malicious code execution, external transmission, and unauthorized credential use as separate stages. Investigate periods when caches remained active.
  • For Administrators: Identify affected caches and templates using official procedures, perform cache deletion, updates, re-fetching, and rotate secrets that were accessible in the execution environment.
  • For Users: If you may have used an affected workspace, follow administrative guidance regarding SSH key rotation and the revocation of OIDC tokens.

Leave a Reply