Coder, registre compromis : des modules Terraform malveillants dérobaient des identifiants cloud et des jetons d’IA

Requêtes redirigées vers des serveurs contrôlés par l’attaquant

L’infrastructure associée à registry.coder.com, le registre principal des modules Coder, a été compromise et utilisée pour distribuer des packages Terraform altérés. L’incident est classé Critical, avec un score CVSS v4 de 9,0 sur 10.

Un acteur non identifié a obtenu l’accès à l’infrastructure Cloudflare de Coder et ajouté des adresses IP non autorisées au pool de serveurs associés au registre. Cloudflare a ainsi acheminé une partie des requêtes des utilisateurs vers des systèmes contrôlés par l’attaquant, plutôt que vers les serveurs légitimes.

Les systèmes malveillants reproduisaient le fonctionnement du registre et fournissaient des artefacts contenant du code malveillant. Toutes les requêtes n’ont pas nécessairement abouti sur l’infrastructure contrefaite : la répartition dépendait de l’équilibrage du trafic entre les adresses présentes dans le pool.

La fenêtre d’exposition s’étend du 31 août 2026 à 07:35 UTC au 31 août 2026 à 21:45 UTC. L’avis de sécurité, publié le 1er septembre 2026 sous le titre « Malicious Packages Served from Unauthorized Registry Server », indique que tout déploiement ayant récupéré un module pendant cette période doit être considéré comme potentiellement exposé.

La compromission concerne un composant sensible de la chaîne de développement. Coder est utilisé pour fournir des environnements cloud de développement sécurisés et self-hosted, notamment pour concevoir et déployer des applications d’intelligence artificielle. Parmi les organisations citées comme utilisatrices de la plateforme figurent Dropbox, Palantir, Square, Mercedes-Benz, KKR, EnBW, le gouvernement américain et des entreprises du secteur de la défense. On ignore quelles clientes et quels clients ont effectivement reçu les modules altérés.

Le stealer dissimulé dans les modules Terraform

Les packages malveillants fonctionnaient comme un information stealer au sein de l’environnement dans lequel le provisioner exécutait le code Terraform. Leur objectif était de collecter des identifiants et des configurations susceptibles de permettre l’accès à des infrastructures cloud, des pipelines de développement et des services externes.

Le code recherchait notamment :

• les variables d’environnement et les secrets disponibles sur le provisioner ;
• les clés d’API des fournisseurs cloud ;
• les clés d’API des outils d’intelligence artificielle ;
• les identifiants CI/CD ;
• les secrets enregistrés dans les fichiers de configuration ;
• l’historique du terminal ;
• les jetons OIDC des utilisateurs ;
• les clés SSH configurées ;
• les jetons à usage unique des fournisseurs d’authentification externes ;
• le mot de passe de la base de données Coder ;
• les configurations accessibles lorsque le provisioner était exécuté au sein de coderd.

Les informations collectées étaient envoyées vers coder-infra[.]com, un domaine choisi pour paraître compatible avec l’infrastructure légitime de Coder. L’adresse mentionnée dans l’avis est www[.]coder-infra[.]com, qui aurait été enregistrée le 28 août 2026.

La quantité de données accessibles variait selon l’opération exécutée. Lors du chargement, de la mise à jour ou de la simulation (dry run) d’un template, le provisioner ne recevait pas les secrets ni les informations personnelles de l’utilisateur. Les valeurs déjà présentes sur le provisioner restaient toutefois exposées, notamment les variables d’environnement et les identifiants locaux.

Le risque augmentait lors de la création d’un workspace. Dans ce scénario, le provisioner pouvait recevoir le jeton OIDC de l’utilisateur, la clé SSH associée si elle était configurée, ainsi que les jetons des fournisseurs externes activés pour ce template. Ces derniers étaient à usage unique ; selon Coder, les refresh tokens n’étaient pas transmis.

Si le provisioner fonctionnait au sein de coderd, le code malveillant pouvait également accéder au mot de passe de la base de données et à d’autres paramètres sensibles de la plateforme. La compromission pouvait donc s’étendre au-delà du workspace concerné.

Déploiements et versions concernés

Toutes les versions de Coder antérieures à la 2.37.0 sont concernées. Les versions correctives sont les suivantes :

• 2.37.0
• 2.36.4
• 2.35.7
• 2.34.9

La mise à jour peut donc être effectuée vers la version la plus récente ou vers la version corrigée de la branche supportée utilisée. L’incident ne possède pas d’identifiant CVE.

Un déploiement peut avoir été concerné s’il a téléchargé un module depuis registry.coder.com pendant la fenêtre d’exposition. Cela se produit notamment lors de la création d’un nouveau template ou d’une nouvelle version de celui-ci.

La création d’un workspace peut également déclencher un nouveau téléchargement, principalement lorsque le cache des modules est désactivé dans les paramètres du template. Le cache est activé par défaut. Toutefois, un workspace peut avoir été construit ultérieurement à partir d’une version de template dans laquelle le module altéré avait déjà été mis en cache.

La simple mise à jour du logiciel est donc insuffisante. Un package malveillant présent dans le cache peut continuer à être utilisé lors de nouveaux déploiements, même après le retour du registre à un fonctionnement légitime.

Coder a examiné les versions des templates actuellement disponibles et les a déclarées exemptes de code malveillant. Rien n’indique que des données de clientes ou clients stockées directement par l’entreprise aient été consultées. La reconstitution ne peut toutefois pas être considérée comme complète : les serveurs malveillants étaient externes au contrôle de Coder et leurs journaux ne sont pas entièrement disponibles.

Indicateurs à rechercher dans les journaux et les templates

Les organisations doivent examiner les journaux DNS, les journaux des pare-feu et des proxys, ainsi que les flux VPC, à la recherche de connexions sortantes vers le domaine d’exfiltration. Les principaux indicateurs réseau sont les suivants :

• domaine : www[.]coder-infra[.]com ;
• adresse IP : 199.91.220[.]205 ;
• URL : http://www[.]coder-infra[.]com/cli/check ;
• en-tête HTTP : X-CLI-Token: your-secret-token.

Dans les fichiers Terraform, il faut rechercher un bloc data "external" "telemetry" qui exécute ${path.module}/dlp-docker.sh. Dans les journaux des tâches des provisioners, la chaîne la plus utile pour la détection est :

data.external.telemetry

Les empreintes SHA-256 des fichiers signalés sont les suivantes :

Fichier	SHA-256
dlp-docker.sh	7190a17c593276d7fd71c4863a4bc0b6c957ed14249288e6f64c5540e2c49398
dlp.sh commun	a7f4fa5f7e33b2a6f6488cf28444584caa449144d246b083de919162f5514247
dlp.sh pour Aider	414d01f6072fbf05bef513e277f4c2b504a413c8e2aa5bae133a5cbc0cda9dc1
dlp.sh pour RStudio Server	a64ce3038f2a501c9735abf6a1f9f04cbddbad53371cd68bec0f7510365c8ffa
dlp.sh pour Windows RDP	ebbe0d2ed8cfaf9e19edb38ce44d6b407f9771b5c0813a7add27c05f66e89596
dlp.sh pour Zed	7ef6b8c3c976fb60b3fa22e9e294ba548d9b532e060c1323a0124a3a7a647f13

L’absence de ces empreintes n’exclut pas automatiquement une exposition. Il reste nécessaire de vérifier les dates de téléchargement des modules et les workspaces qui les ont utilisés.

Comment identifier et supprimer les modules du cache

Coder a préparé des requêtes SQL permettant d’identifier les fichiers de modules créés pendant la période de l’incident. Les critères comprennent l’identifiant nul 00000000-0000-0000-0000-000000000000, le type MIME application/x-tar et une date de création comprise entre 2026-08-31 07:35:00+00 inclus et 2026-08-31 21:45:00+00 exclus.

Les recherches mettent en relation les tables des fichiers, des valeurs Terraform, des versions des templates et des templates eux-mêmes. Elles permettent d’obtenir le nom et la version du template, l’identifiant du module, la date de mise en cache et les workspaces ayant utilisé le composant.

Une recherche distincte, nommée SearchLogsForKeyPhrase, examine les journaux des provisioners à la recherche de data.external.telemetry. Les résultats comprennent la tâche, le build, le workspace, le template, le propriétaire ou l’initiateur, le statut et l’heure de démarrage.

Les modules suspects doivent être supprimés avant de redéployer les templates. La procédure officielle crée une table temporaire contenant les identifiants détectés, réinitialise les références cached_module_files, supprime les fichiers de la table files et exécute l’ensemble dans une transaction BEGIN/COMMIT.

Correctif et rotation des identifiants

La réponse doit suivre un ordre précis : identifier les modules concernés, les supprimer du cache, puis mettre à jour Coder vers 2.37.0, 2.36.4, 2.35.7 ou 2.34.9. Coder préparait également une version ultérieure intégrant des procédures automatisées de remédiation.

Tous les identifiants potentiellement accessibles aux provisioners doivent être renouvelés de manière proactive. Les priorités comprennent les clés cloud, les jetons des services d’IA, les identifiants CI/CD, les secrets présents dans les variables d’environnement, les clés SSH, les jetons OIDC et le mot de passe de la base de données Coder.

Il faut également prendre en compte les identifiants présents dans les fichiers de configuration ou dans l’historique du shell. L’impossibilité de démontrer une exfiltration ne permet pas de l’exclure : l’absence de journaux complets des serveurs malveillants empêche toute vérification définitive pour chaque déploiement.