flawopen.com/AI Security/progress-arcgenai-generator-command-injection-cve-2026-91140
CVE-2026-91140 : injection de commandes dans ARCGenAI-Generator
Un document Swagger/OpenAPI conçu à cet effet pouvait influer sur le nettoyage de fichiers temporaires par shell dans ARCGenAI-Generator 2.0 lorsqu’un développeur le lançait. Progress a corrigé le flux en 2.1 ; l’avis ne signale aucune exploitation active.[1], [3], [4]
Une instruction de nettoyage d’atelier reçoit un nom de fichier d’une autre étape, puis le transmet au système d’exploitation. Si ce nom est interprété comme une partie d’une instruction shell plutôt que comme du texte, le nettoyage peut exécuter des commandes imprévues. Le correctif évite le shell lorsque c’est possible et limite puis met entre guillemets tout nom de fichier qui doit encore lui être transmis.[1], [2]
Concepts Clés et Termes
ARCGenAI-Generator- Outil Progress DataDirect qui génère des artefacts de connecteur REST à partir d’entrées Swagger/OpenAPI. La version concernée est 2.0 ; Progress indique que la 2.1 est corrigée.[1], [3]
Document Swagger/OpenAPI- Description structurée d’API fournie au générateur. Les noms de schéma et métadonnées sont des entrées externes et ne doivent pas devenir de la syntaxe shell.[1], [4]
Injection de commandes shell- Défaut de séparation données-commandes où une entrée non fiable modifie la commande interprétée par un shell du système.[1], [4], [5]
Nettoyage des fichiers temporaires- Suppression des fichiers intermédiaires après assemblage. L’avis situe le défaut dans les consignes de nettoyage basées sur le shell.[1], [2]
CWE-78- Neutralisation incorrecte d’éléments spéciaux utilisés dans une commande du système d’exploitation ; attribuée à
CVE-2026-91140.[4]
Correspondances de référentiels
- Référence CWE pour la faiblesse décrite dans ce guide : CWE-78
Déroulement de l'Attaque Étape par Étape
Des noms issus du document entrent dans le flux
La fiche CVE désigne un document Swagger/OpenAPI préparé comme déclencheur et précise qu’un développeur doit lancer le générateur. Le commit public du correctif montre que le nettoyage reçoit {fileName} de l’orchestrateur ; les sources citées n’établissent pas que ce nom provient du document.[1], [2]
Les consignes de nettoyage atteignent le shell
Les instructions publiques de l’agent avant le correctif utilisaient le terminal pour nettoyer les fichiers temporaires et interpolaient {fileName} dans des chemins. Le commit indique que cette valeur est reçue de l’orchestrateur ; les sources citées n’établissent pas qu’elle provient du document.[2]
Le système peut interpréter l’entrée comme de la syntaxe
Un document conçu à cet effet peut faire exécuter des commandes imprévues par l’instruction de nettoyage, dans le contexte du processus du développeur. La fiche CVE décrit une exécution de commandes sur son poste ; elle ne publie pas de chaîne précise et n’affirme pas que chaque exécution du générateur soit vulnérable.[1], [4], [5]
Code Source : Vulnérable vs Sécurisé
Le panneau vulnérable cite les instructions de l’agent Progress avant le correctif. Le panneau corrigé résume les changements du commit 7ede6d9 : privilégier les opérations natives, valider les noms avec l’allowlist et mettre chaque expansion entre guillemets si un recours au shell est nécessaire. Les commandes de nettoyage exécutables et les entrées d’exploitation sont omises.[2]
# Avant le correctif de Progress : instructions de l’agent pour nettoyer les fichiers temporaires
After successful assembly, delete temp files using the terminal with shell-native commands.
Use retry logic to handle transient file locks.
# Correctif de Progress : privilégier une opération native lorsque c’est possible
Prefer your file-editing tool's native delete/remove capability over the terminal.
Removing temp files is a plain file-system operation — it does not need a shell.
# Si un recours au shell est nécessaire, validez {fileName} avec ^[A-Za-z0-9._-]+$
# et placez chaque expansion entre guillemets dans les instructions de nettoyage propres à la plateforme.
Liste de Contrôle de Sécurité pour l'Ingénierie
- ✓Inventoriez les installations d’ARCGenAI-Generator, les copies dans les dépôts et les espaces développeur ou CI ; vérifiez la version du produit, pas seulement celle du connecteur parent.[1], [3]
- ✓Mettez ARCGenAI-Generator à niveau vers la version 2.1 ou ultérieure. Dans l’intervalle, ne traitez pas de documents Swagger/OpenAPI non fiables avec la version 2.0.[1], [3]
- ✓Examinez les instructions corrigées de
.github/agents/ARCGenAI-Generator.agent.md: opérations natives privilégiées,{fileName}soumis à une allowlist et expansions shell entre guillemets.[2] - ✓Recommandation FlawOpen : Traitez les spécifications d’API et les noms issus du schéma comme des entrées non fiables pendant la génération, le nettoyage et la validation ; ne supposez pas que l’agent séparera données et commandes sans contrôles explicites.
- ✓Recommandation FlawOpen : Exécutez les outils développeur avec le minimum de privilèges et, si possible, isolez la génération des dépôts source, du matériel de signature, des identifiants cloud et des secrets de production.
- ✓Recommandation FlawOpen : Ajoutez des tests de régression non destructifs pour l’allowlist des noms et le choix d’un nettoyage sans shell ; utilisez des noms inoffensifs et uniquement des fixtures temporaires de test.
- ✓Recommandation FlawOpen : Pour les espaces développeur ou CI ayant exécuté ARCGenAI-Generator 2.0 avec des documents non fiables, examinez la télémétrie disponible des processus et fichiers autour de ces exécutions. Son absence constitue une lacune d’assurance, pas une preuve de compromission ni d’innocuité.