Cybersecurity

Compromise of Coder Registry Infrastructure Used to Deliver Malicious Terraform Modules

Attackers gained unauthorized access to Cloudflare’s Coder infrastructure to add servers to the module registry, leading to the distribution of modified Terraform modules containing code to steal secrets and credentials. Coder recommended rotating secrets, inspecting logs, and deleting cached packages, while acknowledging that it could not determine all affected deployments.

2026-09-03
3 min read
3 views
فريق تحرير certi.news
Compromise of Coder Registry Infrastructure Used to Deliver Malicious Terraform Modules

Coder disclosed a compromise of its software registry infrastructure, registry.coder.com, which enabled an attacker to add unauthorized servers to the infrastructure it operates through Cloudflare. As a result, some download requests were redirected to the attacker’s servers instead of Coder’s legitimate servers, leading to malicious versions of Terraform modules being delivered to a group of users.

The malicious-file distribution window occurred on August 31 between 07:35 and 21:45 UTC, according to Coder’s statement. The modified modules targeted environments running provisioning tools, as they contained code that functioned as an information-stealing tool when executed on affected devices.

What data was exposed?

The malicious modules searched for a wide range of secrets and credentials present in the user’s environment, including:

  • Environment variables and secrets belonging to Provisioner processes.
  • Cloud infrastructure and artificial intelligence tool API keys.
  • CI/CD system credentials.
  • Secrets in configuration files and terminal history.
  • OIDC tokens and configured SSH keys, as well as single-use external authentication tokens.
  • Coder database passwords and other secrets when the Provisioner operates inside coderd.

The collected data was sent to the lookalike domain coder-infra[.]com. Coder recommends that potentially affected users rotate all secrets listed as soon as possible.

Verification and remediation steps

Before upgrading to the patched versions 2.37.0, 2.36.4, 2.35.7, or 2.34.9, Coder asked users to inspect firewall, proxy, and DNS logs, as well as VPC flows, for connections to the malicious domain. Developers should also search Provisioner logs for data.external.telemetry, identify modules downloaded during the exposure window, and delete potentially tampered packages from the cache.

Coder also provided an SQL query to help identify cached modules and template versions that may be affected.

Why does this compromise matter?

The risk here is not limited to a maliciously published software package; it extends to a trusted distribution point that developers rely on to build templates for work environments and infrastructure. In addition, the nature of the secrets targeted by the modules includes cloud keys, artificial intelligence tools, and CI/CD environments, making the incident directly relevant to development, platform, and security teams.

Coder said that update tokens were not passed to the Provisioner and that it found no evidence that customer data it stores was affected. At the same time, it acknowledged that the infrastructure used by the attacker lies outside its control, meaning it does not have important logs and cannot definitively identify every deployment that was compromised. This gap makes rotating secrets and independently reviewing logs necessary measures even in cases where there is no direct evidence of leakage.

News source
BleepingComputer
Open original source ↗
ف
Author

فريق تحرير certi.news

In the same category

You may also like

View all news