Une vulnérabilité d’injection de commandes récemment révélée dans le glob CLI — l’un des utilitaires les plus utilisés de l’écosystème JavaScript — a exposé d’innombrables pipelines CI à un risque de compromission silencieuse.
La faille permet à des attaquants d’exécuter des commandes arbitraires en contrôlant simplement un nom de fichier traité par glob -c.
« Cette vulnérabilité aurait pu permettre une exécution de code à distance sur les systèmes qui hébergent les logiciels que nous utilisons chaque jour. Lorsqu’un outil de confiance, téléchargé des millions de fois par semaine, peut servir à exécuter les commandes d’attaquants, nous devons commencer à le considérer comme un risque lié à la chaîne d’approvisionnement », a déclaré Stanislav Fort, fondateur et directeur scientifique d’AISLE.
Il a ajouté : « Un seul nom de fichier malveillant fourni dans une pull request aurait pu compromettre des secrets ou rendre silencieusement vulnérables les artefacts de build et les pipelines de publication. Même si les correctifs sont disponibles, cette vulnérabilité rappelle que les outils que nous considérons comme allant de soi dans notre travail quotidien peuvent être exploités par des attaquants pour accéder à des voies d’attaque que nous n’avions pas identifiées. »
L’impact de la vulnérabilité de Glob CLI
La CVE-2025-64756) affecte les versions 10.2.0 à 11.0.3 de glob et concerne tout workflow utilisant l’interface CLI avec l’option -c/–cmd.
Avec plus de 10 millions de téléchargements hebdomadaires, glob est au cœur des outils de build, des scripts d’automatisation et des plateformes CI/CD dans de nombreux secteurs.
Tout environnement qui traite des noms de fichiers non fiables — comme les pull requests, les archives extraites ou les fichiers importés par des utilisateurs — a pu être exposé.
Les chercheurs avertissent que cette faille illustre les risques croissants inhérents aux chaînes d’approvisionnement logicielles et aux outils destinés aux développeurs.
Comment la faille de Glob CLI permet l’injection de commandes
La cause profonde du problème réside dans la manière dont l’interface CLI de glob a implémenté l’option -c.
Alors que cette fonctionnalité devait exécuter une commande sur les fichiers correspondant à un motif glob, les versions concernées transmettaient directement ces noms de fichiers à un shell système en utilisant shell: true.
Cela créait une ambiguïté dangereuse, car les shells POSIX interprètent des caractères tels que les guillemets, les accents graves, les pipes et autres métacaractères comme une syntaxe exécutable plutôt que comme du texte littéral. $(…)
Par conséquent, un nom de fichier malveillant pouvait sortir de sa position d’argument et exécuter des commandes arbitraires.
Comme ce comportement permettait l’exécution complète de code, le vol d’identifiants et la falsification de la chaîne d’approvisionnement, la vulnérabilité obtient un score CVSS de 7,5 (élevé).
Son exploitation demande très peu d’efforts aux acteurs malveillants.
Un seul nom de fichier conçu à cet effet — par exemple $(touch injected_poc) — suffit à transformer en arme n’importe quel workflow qui invoque l’interface CLI de glob avec l’option -c.
Ce risque est particulièrement grave dans les environnements d’intégration continue (CI). Lorsqu’un job exécute une commande telle que glob -c echo “**/*”, l’interface CLI de glob recherche récursivement les fichiers du dépôt et transmet tous les noms de fichiers à la commande echo.
Dans des conditions normales, cette commande afficherait simplement la liste des fichiers. Mais comme les versions vulnérables de glob exécutaient les commandes via un shell, les noms de fichiers étaient directement insérés dans une chaîne de commande shell.
Si un seul de ces noms de fichiers contient des métacaractères shell ou une syntaxe de substitution de commande, le shell l’interprète comme du code actif plutôt que comme un nom de fichier.
En pratique, cela signifie qu’un nom de fichier malveillant tel que $(touch injected_poc) devient une instruction plutôt qu’une chaîne inoffensive.
Dès que le job CI invoque glob -c echo “**/*”, le shell évalue la charge utile intégrée et exécute touch injected_poc avec les privilèges du runner CI.
Ces privilèges incluent souvent l’accès au code source, aux variables d’environnement, aux identifiants cloud et aux jetons de publication de logiciels.
Ce qui semble être une simple étape d’affichage de la liste des fichiers devient l’exécution silencieuse de commandes contrôlées par l’attaquant, ce qui en fait une menace importante pour la chaîne d’approvisionnement.
Aucune interaction utilisateur n’est nécessaire au-delà du déclenchement d’un workflow CI sur un dépôt contenant un seul nom de fichier malveillant.
Principales mesures pour réduire les risques liés à la chaîne d’approvisionnement
Pour réduire l’exposition à cette vulnérabilité et renforcer la sécurité des pipelines, les organisations doivent adopter une approche à plusieurs niveaux.
- Mettre à niveau vers une version corrigée de glob (v10.5.0, v11.1.0 ou v12.0.0) et remplacer toute utilisation de glob -c par l’option plus sûre –cmd-arg/-g.
- Auditer les bases de code, les workflows CI et les scripts d’automatisation à la recherche de mécanismes fondés sur un shell ou de traitements dangereux des noms de fichiers, et supprimer ou remanier toute commande qui invoque implicitement un shell.
- Traiter tous les noms de fichiers comme des entrées non fiables en validant, en nettoyant ou en isolant les fichiers contenant des métacaractères shell, en particulier dans les pipelines CI, les services de traitement de fichiers et les workflows d’importation par les utilisateurs.
- Segmenter et renforcer les environnements CI/CD en isolant les jobs non fiables, en limitant les privilèges et en utilisant des identifiants éphémères ou strictement limités.
- Limiter l’exécution de shells au sein des runners CI en privilégiant les modes d’exécution sans shell et en imposant des configurations à moindres privilèges pour toutes les étapes automatisées.
- Restreindre ou surveiller l’accès réseau sortant depuis les environnements CI afin de détecter ou de bloquer les activités suspectes, comme la création non autorisée de fichiers, l’accès à des identifiants ou les tentatives d’exfiltration externe.
- Adopter des mesures de protection plus larges pour la chaîne d’approvisionnement — comme la signature des artefacts, le suivi de leur provenance et l’audit régulier des scripts — afin de détecter les falsifications et d’empêcher la propagation en aval de builds compromis.
Ces mesures contribuent à renforcer la résilience face à cette menace et aux menaces similaires qui pèsent sur la chaîne d’approvisionnement.
Les risques cachés des outils de développement du quotidien
Cette vulnérabilité montre combien des décisions de conception négligées dans des outils de développement courants peuvent introduire de graves risques de sécurité.
Dans ce cas, le problème ne venait pas d’une erreur de programmation, mais d’une hypothèse sur la manière dont les noms de fichiers seraient traités — une faille que les scanners traditionnels peuvent ne pas détecter.
À mesure que les organisations dépendent davantage de l’automatisation et des outils open source, les failles des utilitaires de build peuvent rapidement se propager dans la chaîne d’approvisionnement logicielle.
La CVE-2025-64756 rappelle concrètement que même les fonctionnalités courantes des workflows méritent un examen attentif afin d’éviter toute exposition involontaire.
Ce défi explique pourquoi de plus en plus d’organisations adoptent des approches zero trust pour mieux contrôler la manière dont les outils, les utilisateurs et les workflows automatisés interagissent au sein de la chaîne d’approvisionnement logicielle.