Coder piraté via son vrai registre : des secrets cloud ont pu fuiter

Le 31 août 2026, entre 07 h 35 et 21 h 45 UTC, des requêtes envoyées au registre officiel de Coder ont été dirigées vers des serveurs contrôlés par un attaquant. Des modules Terraform modifiés ont ainsi été distribués depuis registry.coder.com après l’ajout d’adresses IP non autorisées à l’infrastructure Cloudflare, selon les faits recoupés par BleepingComputer.

Une installation Coder ayant téléchargé puis exécuté l’un de ces modules pendant la fenêtre du 31 août peut avoir exposé les secrets accessibles à son provisioner : clés cloud, identifiants CI/CD, jetons OIDC, clés SSH ou données de configuration. Utiliser le domaine légitime ou verrouiller une version ne suffisait pas, car l’artefact altéré arrivait par le canal attendu et pouvait conserver le numéro de version demandé.

Déterminer si une installation a réellement été exposée

La présence de Coder dans l’environnement ne prouve pas, à elle seule, une compromission. L’incident concerne les déploiements ayant récupéré un module du registre pendant la fenêtre à risque, principalement lors de la création ou de la mise à jour d’un template, d’un dry run, ou de la construction d’un workspace lorsque le cache de modules était désactivé. Ce cache est activé par défaut.

L’avis de sécurité de Coder fournit des requêtes SQL pour retrouver les modules mis en cache entre 07 h 35 et 21 h 45 UTC, les versions de templates associées et les workspaces qui les ont utilisées. Il précise aussi que Coder ne peut pas identifier de façon concluante toutes les installations touchées, les échanges éventuels ayant transité par une infrastructure détenue par l’attaquant.

L’examen peut donc suivre trois branches. Si aucune opération susceptible de télécharger un module n’a eu lieu pendant la fenêtre, ce scénario précis peut être écarté. Si une telle opération apparaît sans indicateur supplémentaire, il faut préserver et analyser les journaux ainsi que le cache. Si un indicateur est retrouvé, ou si les traces nécessaires ont disparu, les secrets accessibles au provisioner doivent être considérés comme potentiellement compromis.

Pourquoi le bon domaine et une version verrouillée n’ont pas protégé les clients

Le détournement touchait le chemin de distribution lui-même. Le client contactait bien registry.coder.com, mais Cloudflare pouvait acheminer sa requête vers une adresse frauduleusement ajoutée au pool du registre. Une règle autorisant ce domaine voyait donc une destination conforme alors que le serveur situé derrière celle-ci renvoyait un contenu altéré.

Le verrouillage du numéro de version ne constituait pas non plus une preuve d’intégrité. L’analyse d’eSecurity Planet rappelle que le fichier .terraform.lock.hcl consigne les fournisseurs et leurs empreintes, mais ne suit pas actuellement les modules distants. Un registre compromis pouvait donc servir un artefact différent sous la version exacte demandée.

L’incident ne reposait ainsi ni sur un domaine inconnu ni sur l’adoption accidentelle d’une nouvelle version. Les contrôles continuaient à reconnaître l’adresse et le numéro attendus tandis que le contenu livré avait changé. Pour ce type d’attaque, l’intégrité de l’artefact et les traces de son exécution sont plus probantes que la seule identité logique du registre.

Préserver les traces, puis purger et mettre à jour

Les journaux utiles doivent être conservés avant toute suppression. Les équipes doivent rechercher dans les traces de pare-feu, de proxy, de DNS et de flux VPC les connexions sortantes vers coder-infra.com. Dans les journaux des provisioners, la chaîne data.external.telemetry signale le bloc Terraform ajouté aux modules malveillants.

1. Reconstituer les créations et mises à jour de templates, les dry runs et les constructions de workspaces pendant la fenêtre d’exposition.
2. Exécuter les requêtes SQL publiées pour identifier les modules mis en cache, les versions de templates et les workspaces correspondants.
3. Préserver les journaux réseau et de provisionnement, puis rechercher le domaine coder-infra.com, l’adresse 199.91.220.205, les scripts dlp.sh et dlp-docker.sh ainsi que leurs empreintes publiées.
4. Supprimer du cache les modules récupérés pendant la fenêtre avant tout nouveau déploiement.
5. Installer une version corrigée correspondant à la branche utilisée : 2.37.0, 2.36.4, 2.35.7 ou 2.34.9.

La purge et la mise à jour ne répondent pas au même risque. La première empêche la réutilisation d’un artefact déjà téléchargé ; la seconde applique les correctifs et remédiations du produit. Aucune des deux ne révoque un secret qui aurait déjà été transmis hors de l’environnement.

Renouveler les secrets selon leur portée

La priorité dépend des droits attachés à chaque identifiant. Viennent d’abord les clés d’administration cloud, les secrets CI/CD permettant de publier ou déployer, les clés SSH et les mots de passe de bases de données. Suivent les clés d’outils d’IA, les secrets présents dans les fichiers de configuration ou les variables d’environnement, puis les identifiants récupérables dans l’historique du terminal.

Le contexte d’exécution resserre ce périmètre. Lors de l’importation, de la mise à jour ou du dry run d’un template, le risque portait sur les variables et secrets du provisioner, sans transmission des secrets propres à l’utilisateur. Pendant la construction d’un workspace, le code pouvait aussi accéder au jeton OIDC de l’utilisateur, à sa clé SSH lorsqu’elle était configurée et à des jetons à usage unique de fournisseurs d’authentification externes ; les jetons de rafraîchissement n’étaient pas transmis au provisioner.

Si le provisioner fonctionnait dans coderd plutôt que comme service séparé, le périmètre pouvait également englober le mot de passe de la base Coder et d’autres variables de configuration. Après la rotation, les journaux des services associés doivent être examinés pour détecter une utilisation anormale des anciens identifiants postérieure à l’incident.

À ce stade, aucun élément public n’indique que les données clients conservées par Coder ont été touchées. Cette constatation ne permet toutefois pas d’innocenter une installation particulière, et la méthode d’accès initiale à l’environnement Cloudflare comme l’identité de l’attaquant restent inconnues. La conclusion dépend donc, pour chaque exploitant, de sa chronologie, de ses journaux, de son cache et des secrets auxquels ses provisioners avaient accès.

À lire aussi:

• Hide My Email reste en @icloud.com, mais les développeurs ont un autre domaine à accepter
• SAS ou SARL : le vrai choix se joue sur le dirigeant et les associés
• Runable lève 21 M$, mais son agent ne lance pas encore toutes les publicités