Des modules Terraform malveillants diffusés depuis l’infrastructure Cloudflare compromise de Coder

31 août 2026. Entre 07 h 35 et 21 h 45 UTC, un attaquant diffuse des modules Terraform malveillants depuis le registre de Coder. 3 septembre 2026. BleepingComputer révèle l’affaire. 4 septembre 2026. Coder publie son avis officiel. Le point saillant : le registre lui-même n’a pas été « piraté » — c’est l’infrastructure Cloudflare qui a été compromise. Pourquoi c’est important : vos modules téléchargés depuis une source « de confiance » l’étaient moins qu’ils n’en avaient l’air.

Contourner le registre par l’infrastructure

Le registre registry.coder.com héberge les modules Terraform que les développeurs utilisent pour construire les templates de leurs espaces de travail. Il est servi derrière Cloudflare. Le 31 août, un acteur non autorisé a compromis une clé API Cloudflare et s’en est servi pour rediriger une partie du trafic du registre vers un serveur qu’il contrôlait.

Conséquence directe : pendant la fenêtre d’exposition, une portion des requêtes a été servie par le serveur de l’attaquant, qui renvoyait des versions falsifiées des modules. Ces modules étaient conçus pour scanner et exfiltrer des identifiants cloud — AWS, GCP, Azure et d’autres — vers le domaine suspect coder-infra[.]com. Coder précise que son code source et son infrastructure Google Cloud n’ont pas été compromis.

Le périmètre de la plateforme donne la mesure du risque. Coder fournit des environnements de développement cloud auto-hébergés, utilisés par des organisations comme Dropbox, Palantir, Square, Mercedes-Benz et KKR, ainsi que par des administrations publiques et des entreprises de défense. Un provisioner compromis dans l’une de ces organisations, c’est potentiellement un accès direct à leur infrastructure.

Ce que volaient les modules

Les modules falsifiés agissaient comme des voleurs d’informations (info stealers). Une fois exécutés sur un hôte, ils recherchaient, selon BleepingComputer :

• les variables d’environnement et secrets du provisioner ;
• les clés API d’infrastructure cloud et d’outils d’IA ;
• les identifiants CI/CD ;
• les secrets de fichiers de configuration et l’historique du terminal ;
• les jetons OIDC utilisateur ;
• les clés SSH configurées ;
• les jetons d’authentification externe à usage unique ;
• les mots de passe de la base Coder lorsque le provisioner tournait dans coderd.

La cible est révélatrice : un provisioner Coder est un poste qui, par construction, touche à l’infrastructure. Le compromettre revient à mettre la main sur les clés du royaume — celles qui donnent accès au cloud, au CI/CD et aux environnements de développement.

Avant de détailler, retenons le plus important : ces modules ne cherchaient pas à casser quelque chose, mais à voler — silencieusement, sans briser le fonctionnement des espaces de travail. Un info stealer bien conçu s’exécute, copie ce qu’il trouve, et s’efface sans laisser de trace visible.

La réponse de Coder et les versions corrigées

Coder dit avoir identifié et remédié l’incident le jour même : les IP malveillantes ont été retirées, le cache purgé, et registry.coder.com est confirmé propre. Mais la fenêtre a duré quatorze heures, et l’infrastructure de l’attaquant étant hors de son contrôle, Coder admet ne pas pouvoir identifier avec certitude toutes les instances compromises.

Les versions corrigées sont 2.37.0, 2.36.4, 2.35.7 et 2.34.9. Coder recommande de passer à la dernière version, qui inclut des étapes de remédiation automatiques, et fournit des requêtes SQL pour identifier les modules en cache et les versions de template affectés. Le conseil prioritaire : inspecter les journaux firewall, proxy, DNS et VPC flow à la recherche de tout trafic sortant vers coder-infra[.]com.

# chercher les connexions vers le domaine de l'attaquant dans les journaux de flux
grep -R "coder-infra.com" /var/log/ 2>/dev/null

# lister les modules en cache susceptibles d'avoir été téléchargés pendant la fenêtre
coder templates list 2>/dev/null

Coder précise enfin que les refresh tokens n’ont pas été transmis au provisioner et qu’aucune donnée client hébergée ne semble avoir été touchée. Une prudence de bon aloi : l’essentiel des secrets volés l’a été sur les hôtes des clients, pas dans les systèmes de Coder.

Ce que ça révèle de la supply chain en 2026

Cette attaque n’est pas le classique « paquet npm malveillant ». L’attaquant n’a pas poussé de code dans un dépôt : il a compromis l’infrastructure de livraison — le tuyau par lequel passe le code de confiance. C’est un changement de niveau. Faire confiance à « le registre officiel » devient conditionnel, car le registre lui-même dépend d’une chaîne d’infrastructures tierces.

Le schéma rejoint une tendance documentée ces derniers mois : le détournement BGP qui a servi une mise à jour Virtualizor falsifiée, ou les 77 extensions malveillantes publiées sur le marketplace Open VSX de Coder cet été. Le point commun : la supply chain ne s’arrête plus au code source, elle englobe désormais le réseau, le DNS, les CDN et les clés API des plateformes intermédiaires.

Reste une leçon de gouvernance : la clé compromise était celle d’un fournisseur — Cloudflare — utilisée par Coder. L’incident montre qu’une organisation n’est aussi sûre que le plus faible des tiers qu’elle utilise. Auditer ses propres systèmes ne suffit plus ; il faut aussi évaluer les clés API et les accès de ses prestataires. Enfin, un incident de registre ne se clôt pas à la remédiation technique : il exige une revue des secrets qui ont pu transiter pendant la fenêtre d’exposition.

Verrouiller sa consommation de modules

L’incident Coder impose une conclusion pratique : un registre, même officiel, est une frontière de confiance parmi d’autres. La parade qui survit à la compromission d’un registre entier tient en trois gestes.

Épingler et vérifier. Verrouillez les versions de vos modules Terraform et enregistrez leurs sommes de contrôle dans votre dépôt. Un module dont la somme change sans que vous l’ayez voulu est un module à ne pas exécuter.

Passer par un miroir privé. Consommer les modules publics à travers un registre interne que vous contrôlez réduit la surface : vous auditez ce qui entre, et vous coupez l’accès direct aux registres publics depuis vos pipelines.

Vérifier la provenance. Pour les modules sensibles, exigez des signatures ou des artefacts signés, et revoyez les autorisations des clés API de vos plateformes intermédiaires (CDN, DNS, registre) — c’est là que Coder a été frappé.

Rappelons l’échelle du risque : la fenêtre a duré quatorze heures, soit une journée de travail complète sur plusieurs fuseaux horaires. Beaucoup d’organisations ont pu provisionner des modules « de confiance » sans soupçonner qu’ils venaient d’un serveur contrôlé par l’attaquant. Et comme le provisioner Coder touche par construction à l’infrastructure, chaque module falsifié était un billet d’entrée potentiel vers le cloud et le CI/CD d’une victime.

Ces gestes ne remplacent pas la vigilance : ils la rendent possible, en donnant à vos équipes un moyen de détecter une falsification plutôt que de la subir.

Verdict

Si vous utilisez des templates d’espace de travail Coder, mettez à jour vers une version corrigée (2.37.0, 2.36.4, 2.35.7 ou 2.34.9) et auditez vos journaux à la recherche de coder-infra[.]com.

Si vous avez provisionné des modules pendant la fenêtre du 31 août, révoquez immédiatement les secrets concernés — clés API cloud, jetons OIDC, clés SSH, identifiants CI/CD — sans attendre la fin de l’audit.

Si vous consommez des modules Terraform publics, épinglez les versions et verrouillez-les par somme de contrôle (checksum) : c’est la seule parade qui survit à la compromission d’un registre entier.

Références

• Coder Blog — Coder Registry Security Incident: What Happened and What to Do, 4 septembre 2026
• GitHub Security Advisory — GHSA-vx42-ghc9-gw65 (Coder)
• BleepingComputer — Coder’s registry infrastructure compromised to push malicious modules, 3 septembre 2026