Vulnérabilité critique dans AIT-GUI de la NASA/JPL : commandes et scripts exposés sans authentification

La faille concerne la console opérationnelle AMMOS

Le 22 août 2026, une vulnérabilité critique a été rendue publique dans le composant AIT-GUI de l’AMMOS Instrument Toolkit, un framework open source développé par la NASA/JPL pour les opérations multi-missions.

AIT-GUI fournit aux opérateurs une console accessible depuis un navigateur. Cette interface permet d’interagir avec des instruments scientifiques et des véhicules spatiaux, d’envoyer des commandes, d’exécuter des séquences et de collecter les données renvoyées par les systèmes contrôlés.

La vulnérabilité est référencée sous l’identifiant GHSA-p9r8-2q67-fp86. Elle est classée Critical, avec un score CVSS de 9.4. Le correctif est disponible dans la version AIT-GUI 2.5.2.

Les versions vulnérables n’ont pas été détaillées. Les installations qui n’utilisent pas la version corrigée doivent donc être considérées comme exposées jusqu’à vérification de la mise à jour.

Un serveur exposé sur toutes les interfaces réseau

Selon l’analyse de Cycode, AIT-GUI démarre un serveur HTTP sans authentification, autorisation, gestion des sessions ni protection contre les attaques Cross-Site Request Forgery, ou CSRF.

Le problème ne se limite pas à l’absence de mécanisme de connexion. La configuration de l’hôte est bien lue par l’application, mais elle n’est ensuite pas utilisée pour déterminer l’adresse d’écoute du service. Le serveur effectue à la place un binding sur :

0.0.0.0

Cette configuration rend le service accessible via toutes les interfaces réseau disponibles. Ainsi, même une configuration telle que host: localhost, qui devrait limiter l’accès à la machine locale, n’empêche pas l’exposition à travers le réseau accessible depuis l’instance.

Un attaquant capable d’atteindre le port du service peut interagir directement avec les routes opérationnelles. Il n’est pas nécessairement tenu de disposer d’un compte.

Les endpoints permettent d’envoyer des commandes et d’exécuter des séquences et des scripts

Le point le plus sensible est l’endpoint :

POST /cmd

La valeur du champ command est interprétée puis transmise directement au bus de commandes. Dans le chemin d’exécution décrit par Cycode, aucune authentification, validation ou vérification intermédiaire suffisante ne semble empêcher l’envoi de commandes arbitraires.

D’autres endpoints opérationnels sont également exposés :

POST /seq
POST /script/run
POST /scripts/load

Les routes /seq et /script/run construisent les chemins des fichiers en concaténant des entrées contrôlées par l’utilisateur avec le répertoire racine prévu par l’application. Aucun confinement cohérent des chemins n’est appliqué.

Une entrée telle que :

../../../../something

peut donc pointer en dehors du répertoire autorisé. Cela crée un scénario de path traversal, susceptible de permettre l’accès à des fichiers situés ailleurs dans le système de fichiers ou l’exécution de scripts non prévus par l’opérateur.

La base de code contient déjà une logique correcte empêchant de sortir du répertoire autorisé. Toutefois, selon les chercheurs, ce contrôle est appliqué à la route /scripts/load et n’a pas été réutilisé de manière uniforme pour /seq et /script/run.

Le risque subsiste derrière un pare-feu

Une installation exposée peut permettre à un attaquant de :

• envoyer des commandes arbitraires à des instruments ou à des véhicules via /cmd ;
• exécuter des séquences via /seq ;
• lancer des scripts côté serveur avec /script/run ;
• tenter d’accéder à des fichiers situés en dehors du répertoire prévu au moyen de chemins manipulés.

L’absence de protection contre les attaques CSRF élargit encore la surface d’attaque. Un opérateur utilisant AIT-GUI depuis son navigateur pourrait consulter une page ou cliquer sur un lien malveillant dans le même environnement.

La page hostile pourrait inciter le navigateur à envoyer des requêtes vers la console. Dans certaines conditions, ces requêtes peuvent être émises sans vérification préalable auprès du service destinataire, contournant ainsi l’attente selon laquelle une requête opérationnelle devrait provenir de l’interface légitime.

Le pare-feu ne constitue donc pas une défense suffisante. Si le navigateur de l’opérateur peut atteindre AIT-GUI et charger des contenus malveillants, l’attaque peut réussir même sans accès direct et interactif de l’agresseur au port de la console.

L’absence d’authentification complique également l’attribution de chaque commande à un utilisateur précis. Les installations exposées avant l’application du correctif doivent être considérées comme potentiellement compromises, même en l’absence d’erreurs immédiatement visibles.

L’analyse a permis de produire des preuves d’exploitation fonctionnelles

Cycode a combiné une analyse du code assistée par l’intelligence artificielle avec une vérification manuelle. Les outils automatisés ont notamment recherché des routes capables de modifier l’état sans authentification, des données de requête transmises à des sous-processus sans assainissement et des configurations lues mais ensuite ignorées.

Les chercheurs ont ensuite reproduit concrètement les anomalies identifiées. Ces travaux ont abouti à la création de preuves de concept fonctionnelles, notamment une démonstration CSRF exécutée avec un véritable navigateur headless.

Lors de ce test, zéro requête preflight réseau n’a été enregistrée. Ce résultat montre que le scénario ne dépend pas nécessairement d’une autorisation préalable du service exposé : le navigateur peut transmettre certaines requêtes cross-origin sans effectuer le contrôle préliminaire généralement associé aux requêtes plus restrictives.

Cycode considère comme confirmées les vulnérabilités reproduites concrètement, en les distinguant des résultats issus uniquement de l’analyse statique du code.

Mesures recommandées aux administrateurs

La mesure prioritaire consiste à mettre immédiatement à jour chaque installation vers AIT-GUI 2.5.2. La simple restriction de l’accès au moyen d’un pare-feu ne doit pas être considérée comme une solution définitive.

Les administrateurs devraient également :

1. vérifier que le port de la console n’est pas accessible depuis des réseaux non fiables ;
2. examiner les journaux relatifs aux commandes, séquences et scripts exécutés avant la mise à jour ;
3. analyser chaque instance exposée comme potentiellement compromise ;
4. ajouter une authentification et des protections CSRF à /cmd, /seq et /script/run ;
5. s’assurer que le serveur utilise réellement l’hôte configuré au lieu d’effectuer un binding sur 0.0.0.0 ;
6. appliquer à /seq et /script/run la même logique de confinement des chemins que celle déjà présente dans /scripts/load.

On ignore si GHSA-p9r8-2q67-fp86 a été ajoutée au catalogue KEV de la CISA, et aucune information n’est disponible concernant d’éventuelles échéances opérationnelles fixées par l’agence. Aucun précédent récent du même éditeur ne figure par ailleurs dans ce catalogue.