Le 4 septembre 2026, Coder a détaillé un incident survenu le 31 août dans son registre de modules. Une clé API Cloudflare compromise a permis à un acteur non identifié d’ajouter des serveurs à la chaîne qui répondait pour registry.coder.com. Pendant une fenêtre de quelques heures, certains téléchargements ont reçu des modules modifiés conçus pour rechercher et exfiltrer des secrets.
Un domaine légitime, une livraison altérée
Le point important n’est pas un faux domaine choisi par l’utilisateur. Coder indique que des requêtes vers le registre habituel pouvaient être redirigées vers un serveur malveillant. Les modules Terraform s’exécutent dans une chaîne de provisioning : ils peuvent donc voir les variables, jetons et fichiers auxquels le provisioner a accès.
Coder précise que son code source et son infrastructure Google Cloud n’ont pas été compromis. Cela ne réduit pas à zéro le risque pour un déploiement qui a récupéré un module pendant la fenêtre indiquée.
Le périmètre dépend de l’usage
Coder décrit surtout les créations ou mises à jour de templates et les workspaces créés avec le cache de modules désactivé comme des cas à vérifier. BleepingComputer rapporte que les modules modifiés recherchaient des identifiants cloud. Security.io souligne que la réponse dépend de la visibilité du provisioner et de l’architecture Coder.
Ces éléments ne permettent pas de déduire que chaque installation a exfiltré des secrets. Ils imposent en revanche une recherche ciblée pour les déploiements qui ont téléchargé des modules durant la fenêtre du 31 août.
Les vérifications à mener
Commencez par recenser les templates, versions de templates et workspaces créés ou mis à jour entre 07:35 et 21:45 UTC. Utilisez les requêtes et indicateurs publiés dans l’avis GitHub Coder, notamment les connexions vers le domaine de collecte mentionné par l’éditeur. Contrôlez les journaux firewall, DNS, proxy et VPC ainsi que les caches de modules.
Mettez à jour Coder vers une version corrigée, retirez les modules ou versions suspectes et reconstruisez les templates après vérification. Conservez les copies et empreintes utiles à l’enquête au lieu de les écraser pendant le nettoyage.
La rotation des secrets est prioritaire
Faites tourner les clés cloud, secrets CI/CD, jetons OIDC, clés SSH, identifiants d’outils IA et variables accessibles aux provisioners concernés. Commencez par les comptes capables de modifier l’infrastructure ou de récupérer d’autres accès. La rotation doit couvrir les secrets réutilisés dans plusieurs environnements.
Un simple changement de version ne révoque pas un jeton déjà lu. Si un indicateur apparaît, isolez le workspace ou le provisioner, préservez les journaux et faites intervenir une équipe d’incident.
Le lien avec Soclyde
Soclyde ne contrôle pas Coder Registry et ne peut pas certifier qu’un module a été intègre. Il peut aider une équipe à générer des secrets uniques et à conserver l’inventaire des accès à renouveler dans des coffres chiffrés local-first, sans multiplier les copies dans des fichiers de configuration.
Cette organisation facilite la rotation après l’analyse, mais elle ne remplace pas la remédiation Coder, la vérification des caches ou la surveillance des sorties réseau.
À retenir
L’incident Coder montre qu’un téléchargement depuis un domaine attendu peut quand même provenir d’une infrastructure altérée. Identifiez les modules récupérés le 31 août, vérifiez les indicateurs, corrigez Coder et révoquez les secrets accessibles. Pour structurer cette rotation, consultez le guide du générateur de mots de passe sécurisé ou contactez Soclyde.
