Coder Registry Compromise Pushed Credential-Stealing Terraform Modules

A Coder registry compromise turned a trusted developer module source into a credential-theft channel on August 31, 2026. An unidentified attacker gained access to Coder’s Cloudflare infrastructure and added unauthorized IP addresses to the server pool behind registry.coder.com.

Cloudflare consequently routed some legitimate registry requests to attacker-controlled servers. Those servers returned modified Coder registry artifacts containing malicious code. Coder says affected modules could collect cloud infrastructure credentials, AI-tooling API keys, CI/CD credentials, OIDC tokens, SSH keys and other secrets available to provisioners.

Coder published security advisory GHSA-vx42-ghc9-gw65, rated Critical with a CVSS v4.0 score of 9.0. GitHub lists Coder versions 2.37.0, 2.36.4, 2.35.7 and 2.34.9 as patched versions. It also instructs potentially affected users to identify and clear malicious cached modules before performing a fresh deployment and to update Coder.

Coder registry compromise at a glance

Coder says deployments may have been affected if they downloaded a Coder Registry module during the exposure window, primarily when creating new templates or template versions, or during workspace creation when module caching was disabled.

How the Coder registry compromise created a malicious delivery path

Coder Registry provides reusable Terraform modules that teams can add to Coder workspace templates. The templates themselves define the underlying workspace infrastructure, which can include environments such as cloud virtual machines, containers or Kubernetes workloads.

The attacker did not simply create a convincing fake registry domain.

Instead, Coder says the unidentified actor accessed its Cloudflare infrastructure. The attacker then added unauthorized IP addresses to the pool serving Coder’s module registry.

Those IP addresses hosted a modified version of the registry containing malicious artifacts. Cloudflare subsequently directed some requests for the legitimate registry.coder.com service to those unauthorized servers.

That distinction makes the attack particularly important.

Users could request modules from the expected Coder registry hostname yet receive attacker-modified artifacts. If a deployment received an affected module, the malicious code could execute during template operations or a workspace build.

Coder identified two primary execution scenarios

First, malicious modules could run when teams uploaded or updated templates or performed template dry runs. In this case, Coder says the primary exposure involved environment variables and secrets available on the provisioner.

Second, the malicious modules could run during a workspace build, when the provisioner receives additional secrets including the user’s OIDC token, a configured SSH key and single-use tokens for configured external authentication providers. Coder says refresh tokens are not passed to the provisioner.

If the provisioner ran as part of coderd rather than as a separate service, Coder says this likely also leaked configuration variables such as the database password, external authentication provider information and other configuration.

What the Coder registry compromise put at risk

The malicious Terraform modules functioned as credential-stealing software rather than conventional destructive malware.

According to Coder, potentially accessible information included:

• Provisioner environment variables and secrets
• Cloud infrastructure API keys
• AI-tooling API keys
• CI/CD credentials
• Secrets stored in configuration files
• Terminal history
• User OIDC tokens
• Configured SSH keys
• One-time external authentication tokens
• Coder configuration secrets when provisioners ran within coderd

The malicious code used dlp.sh and dlp-docker.sh files. Coder also identified a Terraform data.external.telemetry block invoking the malicious script.

The code was designed to exfiltrate collected credentials to coder-infra[.]com, a lookalike domain outside Coder’s control. This does not establish that data was successfully exfiltrated from every potentially affected deployment.

This creates a wider problem than losing one developer password. A provisioner can sit at the intersection of development infrastructure, cloud services, CI/CD systems and AI tooling.

Secrets exposed there may therefore provide access to several separate systems.

Why Coder cannot identify every affected deployment

The exposure window ran from 07:35 UTC until 21:45 UTC on August 31, 2026.

However, downloading a module during that period does not automatically prove that a deployment received malicious code.

Coder states that only a subset of users received the malicious artifacts. Because the rogue infrastructure belonged to the attacker, Coder does not possess the logs needed to conclusively determine every affected deployment.

Potential exposure primarily applies to organizations that created new templates, updated template versions, ran template dry runs or deployed workspaces under relevant caching conditions during that window.

Coder reported no indication that customer data maintained by Coder itself was affected.

Organizations should therefore distinguish between potential exposure and confirmed credential loss during incident response.

How to investigate the Coder registry compromise

Coder recommends examining several telemetry sources before concluding that an environment was unaffected.

Security and platform teams should review:

• Firewall logs
• Proxy logs
• DNS logs
• VPC flow logs

Investigators should specifically search for outbound connections to coder-infra[.]com.

Coder also recommends searching provisioner job logs for data.external.telemetry. This string can help identify execution associated with the malicious Terraform code.

The advisory provides SQL queries for finding modules fetched during the exposure window and identifying associated templates or workspaces.

Organizations should also clear potentially affected modules from Coder’s cache before performing fresh deployments.

Update Coder and rotate potentially exposed secrets

Coder lists 2.37.0, 2.36.4, 2.35.7 and 2.34.9 as patched versions.

After investigating and clearing potentially malicious cached packages, organizations should update their Coder deployments to an appropriate patched release.

Credential rotation is equally important.

Coder specifically recommends rotating credentials that may have been accessible to workspace provisioners. Priority targets include:

• Cloud infrastructure API keys
• AI-tooling credentials
• CI/CD secrets
• Secrets stored in environment variables
• Credentials in configuration files
• Credentials exposed through terminal history
• Affected OIDC or external authentication credentials
• SSH keys where applicable
• Coder configuration secrets potentially exposed through coderd

Rotation scope should reflect what each affected provisioner could actually access.

Where Hexnode fits into Coder incident response

The Coder supply-chain attack primarily requires investigation within Coder, its provisioners, network telemetry and potentially exposed cloud or developer credentials. Endpoint security controls provide an additional layer when affected infrastructure includes managed endpoints.

Hexnode can strengthen security across managed developer endpoints, identity access and workstation posture, but DevOps teams must still update coderd and purge affected Coder module caches at the infrastructure layer.

Investigate suspicious activity on endpoints with Hexnode XDR

Hexnode XDR currently supports Windows and macOS endpoints and provides threat detection, investigation and response capabilities.

If a potentially affected Coder component or related developer system runs on a managed endpoints, security teams can use Hexnode XDR to investigate suspicious endpoint activity associated with the incident.

Hexnode XDR provides process-tree visibility and response actions including process termination, endpoint isolation and file quarantine. It also provides a query engine for threat hunting.

These controls can support endpoint investigation and containment. However, Hexnode XDR does not replace Coder’s incident-specific remediation.

Teams still need to inspect Coder and network logs, remove malicious cached modules, update Coder and rotate potentially exposed secrets.

Maintain security baselines on managed engineering endpoints with Hexnode UEM

Hexnode UEM can support the management of developer and administrator endpoints surrounding the affected environment.

Documented capabilities include endpoint compliance, configuration policies, application management, OS and supported application updates, and advanced scripting.

For example, IT administrators can use Hexnode Genie AI to generate custom Bash scripts from natural-language instructions. Teams could create scripts to search supported managed endpoints for incident indicators such as dlp.sh or dlp-docker.sh, then review and validate the generated code before deployment. Hexnode’s scripting capabilities can also support diagnostic collection and organization-specific remediation tasks.

However, Coder itself should be updated through the deployment or package workflow used by the organization. Hexnode UEM should not be positioned as automatically patching Coder or Terraform modules.

Featured resource

Why XDR Is Stronger With UEM

Learn how combining UEM and XDR brings endpoint management, security context, threat investigation and incident response together.

Download the whitepaper

Restrict access from non-compliant devices

The stolen-secret risk also makes access control relevant after containment.

Hexnode IdP supports conditional access based on factors including user identity and device compliance. It also provides MFA and role-based access controls.

Where protected developer, cloud or SaaS resources are integrated with the organization’s identity architecture, compliance-aware access policies can add another control around credential use.

This does not invalidate a stolen credential or replace secret rotation. Potentially exposed credentials still need to be revoked or rotated according to Coder’s guidance.

What security teams should do after the Coder registry compromise

Organizations that used Coder Registry around the August 31 exposure window should prioritize incident-specific investigation.

1. Identify affected activity. Review template creation, template updates, dry runs and workspace builds during the exposure window.
2. Search for the exfiltration domain. Examine firewall, proxy, DNS and VPC flow logs for coder-infra[.]com.
3. Inspect provisioner logs. Search for data.external.telemetry and correlate findings with affected jobs and templates.
4. Identify cached modules. Use Coder’s published queries to locate modules downloaded during the exposure period.
5. Purge suspicious cached packages. Remove potentially malicious modules before redeploying workloads.
6. Update Coder. Move affected deployments to an appropriate patched release.
7. Rotate potentially exposed credentials. Prioritize cloud, AI, CI/CD, OIDC, SSH and Coder-related secrets based on actual provisioner access.
8. Investigate relevant managed endpoints. Examine suspicious processes, files and connections where affected Coder components interacted with managed systems.
9. Review access controls. Limit sensitive application access according to identity, role and device posture where supported.

Trusted registries can become part of the attack path

The Coder incident demonstrates an unusual supply-chain failure: attackers inserted malicious infrastructure behind the legitimate registry service path.

That allowed a normal request to registry.coder.com to return attacker-modified Terraform modules to some users.

For affected organizations, remediation therefore extends beyond removing a malicious file. Teams need to identify potentially affected modules, templates and workspaces from the exposure window, investigate possible exfiltration and rotate credentials that may have been accessible to affected provisioners.

Endpoint investigation, device management and identity controls can support that response. However, Coder’s own logs, indicators, cache-removal procedures, patched releases and credential-rotation guidance remain the primary remediation path.