Coder, registro comprometido: módulos de Terraform maliciosos robaban credenciales cloud y tokens de IA

Solicitudes redirigidas a servidores controlados por el atacante

La infraestructura vinculada a registry.coder.com, el registro principal de módulos de Coder, fue comprometida y utilizada para distribuir paquetes de Terraform manipulados. El incidente está clasificado como Critical, con una puntuación CVSS v4 de 9.0 sobre 10.

Un actor no identificado obtuvo acceso a la infraestructura de Cloudflare de Coder e introdujo direcciones IP no autorizadas en el pool de servidores asociados al registro. Como consecuencia, Cloudflare enrutó parte de las solicitudes de los usuarios hacia sistemas controlados por el atacante en lugar de dirigirlas a los servidores legítimos.

Los sistemas maliciosos imitaban el funcionamiento del registro y proporcionaban artefactos que contenían código malicioso. No necesariamente todas las solicitudes terminaron en la infraestructura falsificada: la distribución dependía del balanceo del tráfico entre las direcciones presentes en el pool.

La ventana de exposición se extendió entre las 07:35 UTC y las 21:45 UTC del 31 de agosto de 2026. El aviso de seguridad, publicado el 1 de septiembre de 2026 con el título “Malicious Packages Served from Unauthorized Registry Server”, indica que cualquier deployment que descargara un módulo durante esas horas debe considerarse potencialmente expuesto.

La intrusión afecta a un componente delicado de la cadena de desarrollo. Coder se utiliza para proporcionar entornos cloud de desarrollo seguros y self-hosted, también destinados a la creación y el despliegue de aplicaciones de inteligencia artificial. Entre las organizaciones que utilizan la plataforma figuran Dropbox, Palantir, Square, Mercedes-Benz, KKR, EnBW, el Gobierno de Estados Unidos y empresas del sector de defensa. No se sabe qué clientes recibieron efectivamente los módulos manipulados.

El stealer oculto en los módulos de Terraform

Los paquetes maliciosos actuaban como information stealers dentro del entorno en el que el provisioner ejecutaba el código de Terraform. El objetivo era recopilar credenciales y configuraciones que pudieran utilizarse para acceder a infraestructuras cloud, pipelines de desarrollo y servicios externos.

El código buscaba, entre otros elementos:

• variables de entorno y secretos disponibles en el provisioner;
• claves de API de proveedores cloud;
• claves de API para herramientas de inteligencia artificial;
• credenciales de CI/CD;
• secretos almacenados en archivos de configuración;
• historial de la terminal;
• tokens OIDC de los usuarios;
• claves SSH configuradas;
• tokens de un solo uso para proveedores de autenticación externos;
• contraseña de la base de datos de Coder;
• configuraciones accesibles cuando el provisioner se ejecutaba dentro de coderd.

La información recopilada se enviaba a coder-infra[.]com, un dominio elegido para parecer compatible con la infraestructura legítima de Coder. La dirección indicada en el aviso es www[.]coder-infra[.]com, que habría sido registrada el 28 de agosto de 2026.

La cantidad de datos accesibles variaba según la operación realizada. Durante la carga, actualización o ejecución de un dry run de una plantilla, el provisioner no recibía los secretos ni la información personal del usuario. Sin embargo, quedaban expuestos los valores ya presentes en el provisioner, incluidas las variables de entorno y las credenciales locales.

El riesgo aumentaba durante la creación de un workspace. En este escenario, el provisioner podía recibir el token OIDC del usuario, su clave SSH si estaba configurada y los tokens de los proveedores externos habilitados para esa plantilla. Estos últimos eran de un solo uso; según Coder, los refresh tokens no se transmitían.

Si el provisioner operaba dentro de coderd, el código malicioso también podía acceder a la contraseña de la base de datos y a otros ajustes sensibles de la plataforma. Por tanto, el compromiso podía extenderse más allá de un único workspace.

Deployments y versiones expuestos

Están afectadas todas las versiones de Coder anteriores a la 2.37.0. Las versiones que incluyen las correcciones son:

• 2.37.0
• 2.36.4
• 2.35.7
• 2.34.9

Por tanto, la actualización puede realizarse a la versión más reciente o a la versión corregida de la rama compatible que se esté utilizando. El incidente no tiene un identificador CVE.

Un deployment pudo verse afectado si descargó un módulo de registry.coder.com durante la ventana de exposición. Esto ocurre principalmente al crear una plantilla nueva o una nueva versión de una plantilla existente.

La creación de un workspace también puede provocar una descarga nueva, pero principalmente cuando la caché de módulos está deshabilitada en la configuración de la plantilla. La caché está habilitada de forma predeterminada. No obstante, un workspace pudo haberse creado posteriormente utilizando una versión de plantilla en la que el módulo manipulado ya estaba almacenado.

Por este motivo, actualizar únicamente el software no es suficiente. Un paquete malicioso que permanezca en la caché puede seguir utilizándose durante nuevos despliegues, aunque el registro haya vuelto a servir contenido legítimo.

Coder examinó las versiones de las plantillas disponibles actualmente y declaró que están libres del código malicioso. No hay indicios de acceso a los datos de los clientes almacenados directamente por la empresa. Sin embargo, la reconstrucción no puede considerarse completa: los servidores maliciosos estaban fuera del control de Coder y sus registros no están disponibles en su totalidad.

Indicadores que deben buscarse en los logs y las plantillas

Las organizaciones deben revisar los logs de DNS, firewall, proxy y los flujos VPC en busca de conexiones salientes hacia el dominio utilizado para la exfiltración. Los principales indicadores de red son:

• dominio: www[.]coder-infra[.]com;
• dirección IP: 199.91.220[.]205;
• URL: http://www[.]coder-infra[.]com/cli/check;
• cabecera HTTP: X-CLI-Token: your-secret-token.

En los archivos de Terraform debe buscarse un bloque data "external" "telemetry" que ejecute ${path.module}/dlp-docker.sh. En los logs de los jobs de los provisioners, la cadena más útil para su detección es:

data.external.telemetry

Los hashes SHA-256 de los archivos identificados son:

Archivo	SHA-256
dlp-docker.sh	7190a17c593276d7fd71c4863a4bc0b6c957ed14249288e6f64c5540e2c49398
dlp.sh común	a7f4fa5f7e33b2a6f6488cf28444584caa449144d246b083de919162f5514247
dlp.sh para Aider	414d01f6072fbf05bef513e277f4c2b504a413c8e2aa5bae133a5cbc0cda9dc1
dlp.sh para RStudio Server	a64ce3038f2a501c9735abf6a1f9f04cbddbad53371cd68bec0f7510365c8ffa
dlp.sh para Windows RDP	ebbe0d2ed8cfaf9e19edb38ce44d6b407f9771b5c0813a7add27c05f66e89596
dlp.sh para Zed	7ef6b8c3c976fb60b3fa22e9e294ba548d9b532e060c1323a0124a3a7a647f13

La ausencia de estos hashes no descarta automáticamente la exposición. Sigue siendo necesario comprobar cuándo se descargaron los módulos y qué workspaces los utilizaron.

Cómo identificar y eliminar los módulos de la caché

Coder ha preparado consultas SQL para identificar los archivos de módulos creados durante la ventana del incidente. Los criterios incluyen el identificador nulo 00000000-0000-0000-0000-000000000000, el tipo MIME application/x-tar y una hora de creación comprendida entre 2026-08-31 07:35:00+00 —incluida— y 2026-08-31 21:45:00+00 —excluida—.

Las consultas relacionan las tablas de archivos, valores de Terraform, versiones de plantillas y plantillas. Permiten obtener el nombre y la versión de la plantilla, el ID del módulo, el momento en que se almacenó en la caché y los workspaces que utilizaron el componente.

Una consulta independiente, denominada SearchLogsForKeyPhrase, examina los logs de los provisioners en busca de data.external.telemetry. Los resultados incluyen el job, la build, el workspace, la plantilla, el propietario o iniciador, el estado y la hora de inicio.

Los módulos sospechosos deben eliminarse antes de volver a desplegar las plantillas. El procedimiento oficial crea una tabla temporal con los ID identificados, borra las referencias cached_module_files, elimina los archivos de la tabla files y ejecuta todas las operaciones dentro de una transacción BEGIN/COMMIT.

Parcheado y rotación de credenciales

La respuesta debe seguir un orden preciso: identificar los módulos afectados, eliminarlos de la caché y actualizar Coder a 2.37.0, 2.36.4, 2.35.7 o 2.34.9. Coder también estaba preparando una versión posterior con procedimientos automáticos de remediation.

Todas las credenciales a las que potencialmente hayan podido acceder los provisioners deben rotarse de forma proactiva. La prioridad incluye las claves cloud, los tokens de servicios de IA, las credenciales de CI/CD, los secretos presentes en variables de entorno, las claves SSH, los tokens OIDC y las contraseñas de la base de datos de Coder.

También deben tenerse en cuenta las credenciales presentes en archivos de configuración o en el historial del shell. No poder demostrar una exfiltración no equivale a descartarla: la falta de logs completos de los servidores maliciosos impide realizar una verificación concluyente para cada deployment.