Le registre de Coder détourné pour diffuser des modules Terraform piégés

Quatorze heures pendant lesquelles le registre n’était pas le bon

Le 31 août 2026, entre 07 h 35 et 21 h 45 UTC, une partie des requêtes adressées à registry.coder.com n’a pas été servie par Coder. D’après l’avis de l’éditeur, relayé le 3 septembre par Bleeping Computer, un acteur malveillant non identifié a obtenu un accès à l’infrastructure Cloudflare de Coder et ajouté des adresses IP non autorisées au pool utilisé par le registre de modules. Cloudflare a donc dirigé une fraction des requêtes vers des serveurs contrôlés par l’attaquant, qui hébergeaient une version du registre contenant des artefacts malveillants.

Coder est la plateforme qui permet à une organisation de fournir à ses développeurs des environnements de développement cloud auto-hébergés, y compris pour construire des applications d’IA. Son registre héberge les composants que ces équipes utilisent pour composer leurs modèles d’espaces de travail. Parmi les organisations qui s’appuient sur le projet, Bleeping Computer cite Dropbox, Palantir, Square, Mercedes-Benz, KKR, EnBW, le gouvernement américain et des entreprises du secteur de la défense.

Des modules Terraform transformés en voleurs d’identifiants

Ce qui a été distribué pendant cette fenêtre, ce sont des versions modifiées de modules Terraform, ces ensembles d’instructions prêts à l’emploi qui décrivent la création et la configuration d’une infrastructure. Une fois exécutés sur l’hôte, ils se comportaient comme des logiciels de vol d’informations.

La liste de ce qu’ils recherchaient dessine assez précisément le trousseau d’une équipe d’infrastructure : variables d’environnement et secrets du provisionner, clés d’API d’infrastructure cloud et d’outillage IA, identifiants de CI/CD, secrets de fichiers de configuration et historique du terminal, jetons OIDC des utilisateurs, clés SSH configurées, jetons d’authentification externe à usage unique. Lorsque le provisionner tournait à l’intérieur de coderd, s’y ajoutaient les mots de passe de la base de données Coder et d’autres secrets de configuration. Les données collectées étaient exfiltrées vers un domaine sosie, coder-infra[.]com.

Ce que Coder demande de vérifier, et dans quel ordre

L’éditeur recommande aux utilisateurs potentiellement touchés de renouveler dès que possible l’ensemble des secrets concernés. Avant de passer sur une version corrigée — 2.37.0, 2.36.4, 2.35.7 ou 2.34.9 —, il conseille d’examiner les journaux de pare-feu, de proxy, DNS et de flux VPC à la recherche de connexions vers coder-infra[.]com.

Côté applicatif, il faut chercher data.external.telemetry dans les journaux de provisionner, identifier les modules téléchargés pendant la fenêtre d’exposition, puis purger les paquets mis en cache susceptibles d’être malveillants. Coder a également publié une requête SQL permettant de repérer les modules en cache et les versions de modèles potentiellement affectés.

Ce que l’éditeur ne peut pas vous dire

Coder indique que les jetons de rafraîchissement n’étaient pas transmis au provisionner, et qu’aucun élément n’indique un impact sur les données clients dont il a la charge. Mais il pose aussi une limite explicite : l’infrastructure de l’attaquant échappe à son contrôle, il n’a pas accès aux journaux qui permettraient de trancher, et il ne peut donc pas identifier avec certitude chaque déploiement compromis.

L’inventaire de ce qui a été téléchargé le 31 août ne peut être fait que par chaque équipe, sur ses propres journaux. Tant qu’il n’est pas fait, l’hypothèse prudente reste que les secrets présents sur ces hôtes ont changé de mains.