L’équipe de sécurité 0din de Mozilla vient de présenter quelque chose qui mérite l’attention de tout développeur. Dans une preuve de concept, elle a amené Claude Code, l’agent de codage d’Anthropic, à exécuter un logiciel malveillant à partir d’un dépôt GitHub apparemment propre. De plus, l’ensemble du processus s’est déroulé pendant une configuration de projet qui paraissait routinière. Autrement dit, la machine du développeur a été compromise pendant que l’installation suivait son cours normal.
Portanto, vale entender cada etapa desse ataque. Assim, você consegue reconhecer o mesmo padrão no seu próprio fluxo de trabalho.
Mozilla acende o alerta para quem confia em agentes de codificação
La démonstration a commencé de manière simple. D’abord, les chercheurs ont demandé à Claude Code d’initialiser un projet à partir d’un dépôt. Selon le rapport, ce dépôt ne contenait que quelques fichiers de structure rudimentaire et affichait une apparence inoffensive à première vue.
Pourtant, Mozilla a présenté le cas comme une preuve de concept. Ainsi, les récits disponibles pointent vers une expérience contrôlée, réalisée dans un environnement sûr. Néanmoins, la technique révèle un risque réel pour ceux qui utilisent au quotidien des outils d’agents de codage.
Como a cadeia de configuração abriu uma janela para o atacante
L’attaque dépendait d’un comportement attendu de l’agent. Fondamentalement, Claude Code suivait les instructions de configuration du projet. Après avoir cloné le dépôt, il traitait un fichier Markdown contenant une étape apparemment légitime.
Ce fichier instruisait l’agent à initialiser un environnement Python avec Axiom, un outil réel de surveillance. Cependant, le dépôt contenait également un script de démarrage faux pour Axiom. Lorsque ce script échouait, l’agent cherchait une solution par ses propres moyens. Puis, il exécutait une autre commande : python3 -m axiom init.
O registro TXT de DNS como esconderijo perfeito para a carga maliciosa
Voici le point le plus ingénieux de l’attaque. Cette commande déclenchait un script shell. Peu après, le script lisait des enregistrements TXT DNS d’un domaine créé pour la démonstration, le _axiom-config.m100.cloud.
Habituellement, les enregistrements TXT DNS servent à des tâches de configuration, notamment les réglages d’email. Dans ce cas, toutefois, l’enregistrement contenait une chaîne encodée en base64. Dès que l’agent décodait et exécutait cette chaîne, un shell inversé s’ouvrait sur la machine.
Ainsi, l’attaquant obtenait un accès à distance par commande sur l’ordinateur du développeur. Pendant ce temps, l’installation semblait se terminer avec succès. Tant la victime que l’agent ne voyaient qu’un message indiquant que l’environnement était prêt.
Três camadas de indireção mantiveram o repositório aparentemente limpo
La méthode combinait trois niveaux d’indirection. D’abord, un dépôt qui paraissait propre. Ensuite, un paquet qui échouait lors de l’installation et sollicitait une commande d’initialisation. Enfin, un registre TXT DNS qui livrait la charge au moment de l’exécution.
Par conséquent, la charge malveillante restait hors du dépôt cloné. Au contraire, elle arrivait plus tard, via l’enregistrement TXT DNS. Ainsi, la commande dangereuse restait éloignée des fichiers que la plupart des gens examinent avant d’installer.
Ce détail est particulièrement important pour les outils de sécurité. En effet, les tests statiques d’applications et les vérifications des logiciels bills of materials se concentrent sur les fichiers et les dépendances présents dans le dépôt. Comme la charge vivait en dehors, la commande exécutée au runtime restait séparée des fichiers versionnés.
Do shell reverso ao acesso total: o que o atacante realmente conquista
Dès que le shell inversé est actif, l’attaquant opère avec les mêmes privilèges que le compte qui a lancé l’agent. Par conséquent, l’étendue des dégâts croît rapidement.
Selon le rapport de 0din, cet accès peut inclure des secrets, des clés API, du code, des documents, des sessions de navigateur et des mots de passe. De plus, l’attaquant peut installer d’autres malwares pour maintenir l’accès sur le long terme. En somme, une seule négligence dans la configuration ouvre une porte plutôt large.
Números que dimensionam o problema para o ecossistema de desenvolvimento
Les données du marché renforcent l’urgence du sujet. Par exemple, le rapport State of Secrets Sprawl 2026 de GitGuardian a enregistré 28,65 millions de nouveaux secrets insérés dans des commits publics sur GitHub en 2025. Cela représente une hausse de 34 % par rapport à l’année précédente.
De plus, GitGuardian a signalé une augmentation de 81 % des fuites de services d’IA. Par ailleurs, l’enquête Stack Overflow de 2025 a montré que 84 % des répondants utilisent ou prévoient d’utiliser des outils d’IA dans le développement. De même, JetBrains a identifié que Claude Code atteignait 57 % de reconnaissance parmi les développeurs en 2026.
Par conséquent, la surface d’exposition se développe à mesure que l’adoption augmente. Plus les équipes adoptent des agents de codage, plus ce vecteur devient attractif.
Mozilla: Permissões, sandbox e as defesas que o Claude Code já oferece
Heureusement, Claude Code propose des contrôles pour gérer les permissions des outils. Selon la documentation d’Anthropic, vous pouvez visualiser et gérer ces règles via la commande /permissions. Ainsi, l’interface montre les règles appliquées et les fichiers de configuration qui les génèrent.
De plus, la documentation décrit un Bash tool en sandbox. Fondamentalement, il offre une isolation du système de fichiers et du réseau pour l’exécution autonome de l’agent. Il faut rappeler que, dans la démonstration, la charge est arrivée via un registre TXT DNS lors de la configuration. Par conséquent, le contrôle du réseau se révèle aussi important que le contrôle des fichiers.
L’OWASP renforce cette logique dans son Top 10 pour les applications utilisant des LLM. Là, l’agence excessive apparaît comme un risque lié à des systèmes avec une autonomie ou un accès trop large.
O que os pesquisadores recomendam para blindar sua configuração de projeto Mozilla
Les chercheurs ont laissé des conseils très pratiques. En premier lieu, considérez tout dépôt inconnu comme du code à inspecter avec soin. De même, gardez un regard critique sur chaque instruction de configuration, même lorsqu’un agent exécute le travail.
De plus, 0din soutient que les agents de codage affichent l’intégralité de la chaîne d’exécution avant de lancer les commandes de configuration. Autrement dit, le développeur doit pouvoir voir les scripts et le code qui arrivent dynamiquement à l’exécution. De la même manière, les chercheurs recommandent des restrictions réseau pendant l’initialisation et des points d’approbation humaine pour les étapes automatiques.
En résumé, la leçon que tire Mozilla est directe. Inspectez quelles commandes vont être exécutées, ce que ces commandes appellent et comment chaque donnée externe arrive pendant la configuration. Ainsi, vous conservez le pouvoir des agents de codage tout en protégeant votre machine et vos secrets.
Acompanhe nosso perfil no Instagram!
