Security · 3 Sep 2026 · Rob Nidschelm

They Trusted Coder’s Registry. For 14 Hours, It Served Credential Stealers.

A trusted registry can look like infrastructure while behaving like an attacker-controlled software update channel. For 14 hours on 31 August, Coder’s Terraform registry could deliver malicious modules designed to search developer and cloud environments for credentials.

Coder says attackers gained access to its Cloudflare infrastructure and added unauthorised IP addresses to the pool serving registry.coder.com. Requests from a subset of users were then directed to an attacker-controlled registry that returned modified Terraform modules. The payload searched provisioner environments for cloud credentials, CI/CD secrets, AI service keys, SSH material, authentication tokens, configuration files and terminal history.

The malicious code sent the results to coder-infra[.]com. Coder contained the incident at 21:45 UTC, 14 hours and 10 minutes after the malicious service began responding. The company cannot conclusively identify every affected deployment because it does not have the attacker server’s logs.

This is not merely a package-integrity incident. A Terraform module executes where infrastructure is created, often beside the credentials needed to reach clouds, repositories, build systems and production services. The compromised registry therefore sat at a point where code and authority routinely meet.

The source repository did not need to change

Software supply-chain defences often focus on malicious commits, compromised maintainers and altered release artifacts. Coder’s disclosure describes a different trust failure. The attackers did not need to rewrite a legitimate source repository if they could control where the registry sent a request.

The path ran through Cloudflare infrastructure used to serve the registry. By adding hostile addresses to the origin pool, the attackers could make a normal-looking request to the expected domain reach a counterfeit service. From the user’s perspective, the hostname was right and the workflow was familiar. The content behind that trusted route was not. The delivery-layer failure echoes BlackTree’s analysis of a BGP hijack that made Virtualizor install malware as an update: a trusted destination and familiar workflow did not guarantee the integrity of the code returned.

That distinction matters for detection. Repository audit logs and source-code reviews may show nothing unusual. The strongest evidence may instead live in DNS telemetry, firewall logs, proxy records, cached modules and the output of the provisioner that executed them.

Who may have received the malicious module?

Coder says an installation may have been affected if it used a module from registry.coder.com and performed an action that caused the module to be fetched during the exposure window. That can include creating or updating a template, running a dry run, or deploying a workspace with module caching disabled.

The window lasted from 07:35 UTC until 21:45 UTC on 31 August 2026. Existing environments that did not retrieve a module during that period are not automatically affected. Conversely, a dry run can matter even when no production workspace was ultimately created, because the provisioner may already have executed the hostile logic.

Caching changes the scope. It may have prevented some systems from reaching the malicious service, while leaving a poisoned module available after the registry was restored. Coder advises affected organisations to identify modules cached during the incident, purge local copies and rebuild from known-good sources.

The provisioner was the prize

According to Coder, the malicious modules attempted to collect environment variables and files associated with cloud providers, CI/CD platforms, source-control systems and AI development services. The search included configured SSH keys, user OIDC tokens, one-time external-authentication tokens, terminal history and other secrets available to the provisioner.

In deployments where a provisioner ran inside coderd, Coder says database passwords and configuration secrets could also have been exposed. That creates a difficult incident-response problem: the list of credentials at risk is determined by what each provisioner could see, not by a single universal inventory.

Coder says it found no indication that customer data maintained by Coder itself was affected. That is useful scope information, but it does not reduce the urgency for organisations whose own keys may have passed through the compromised execution environment.

Do not wait for a perfect victim list

Because the attacker-controlled server logs are unavailable, Coder cannot provide a definitive list of every organisation that received the malicious module. Teams must build their own answer from local evidence.

Coder recommends searching network telemetry for connections to coder-infra[.]com and provisioner logs for data.external.telemetry. It also published a SQL query to help identify modules used during the incident window. Those checks should cover successful deployments, failed jobs and dry runs.

A positive match should be treated as credential exposure. Removing a cached module stops future execution, but it does not invalidate a secret that may already have left the network. Rotate cloud and AI API keys, repository tokens, CI/CD credentials, OIDC and external-authentication tokens, SSH keys and any application or database secret the affected provisioner could access.

What defenders should do now

• Identify all Coder templates that sourced modules from registry.coder.com.
• Review template changes, dry runs and workspace deployments between 07:35 and 21:45 UTC on 31 August.
• Search DNS, proxy, firewall, VPC flow and endpoint telemetry for coder-infra[.]com.
• Search provisioner output for data.external.telemetry and other unexpected external data sources.
• Purge modules and caches that could have been populated during the exposure window, then retrieve clean copies.
• Rotate every credential available to a confirmed or suspected affected provisioner.
• Review subsequent use of those credentials for new sessions, unusual API calls and persistence.

Teams should also examine the trust model around infrastructure registries. Domain allowlists are not enough when the authorised domain can be routed to an unauthorised origin. Controls such as immutable checksums, signed artifacts, pinned versions, controlled mirrors and egress monitoring can turn a silent registry compromise into a detectable integrity failure.

The registry was part of the execution boundary

Terraform modules are often discussed as reusable configuration. Operationally, they are code that can run with the authority required to build infrastructure. That makes the registry, its delivery network and its origin configuration part of the security boundary.

The Coder incident is a warning for any organisation that imports automation from a trusted service. If the delivery path can change without the artifact proving its own identity, the familiar hostname may offer less assurance than defenders think.

Sources and further reading

• Coder security advisory GHSA-vx42-ghc9-gw65, published 1 September 2026. GitHub provided no publication time.
• BleepingComputer report on the Coder registry compromise, published 3 September 2026 at 16:04 in the publisher’s displayed timezone.