Une nouvelle alerte sécurité concerne AIT-GUI, la console d’opération web liée à l’AMMOS Instrument Toolkit, un ensemble open source de la NASA/JPL destiné à soutenir des systèmes de données au sol. Des chercheurs de Cycode expliquent qu’une combinaison de défauts permet, dans certaines conditions, à un attaquant non authentifié d’émettre des commandes arbitraires vers les instruments et le système de commande d’un vaisseau.
La problématique est sérieuse : les chercheurs décrivent des impacts allant bien au-delà de l’affichage de pages dégradées. L’enjeu principal est la possibilité de faire exécuter des actions réelles côté instruments, depuis une interface web accessible sur le réseau.
Pourquoi AIT-GUI est exposé : écoute réseau et routes sensibles
Selon l’advisory publié le 13 août 2026, la configuration par défaut du serveur web d’AIT-GUI joue un rôle important. Le serveur lit une valeur d’hôte configurée, mais la rejette ensuite, ce qui conduit à lier l’interface réseau sur l’adresse 0.0.0.0 et à ouvrir le port 8080 par défaut.
Dans ce contexte, les chercheurs indiquent que toutes les routes qui modifient l’état ne disposent d’aucune barrière d’authentification ou d’autorisation. Ils mentionnent également l’absence de protection CSRF (Cross-Site Request Forgery) sur ces endpoints.
Autrement dit, si un attaquant atteint le port exposé, il peut potentiellement envoyer des requêtes qui déclenchent des actions sensibles, sans que le serveur exige une identité vérifiée.
La chaîne de vulnérabilités : preuve par les endpoints
La chaîne de problèmes a été suivie sous la référence GHSA-p9r8-2q67-fp86 et notée 9,4 sur la base du scoring CVSS v3.1. L’advisory précise qu’aucune CVE n’a été attribuée à cette série de défauts.
Les versions concernées citées par Cycode incluent AIT-GUI 2.5.1 et antérieures. Le correctif mentionné est présent dans la version 2.5.2 (sortie le 12 août 2026).
Concrètement, l’advisory liste trois endpoints particulièrement problématiques pour les AIT-GUI commandes abusives :
- POST /cmd : permet d’émettre des commandes arbitraires pour les instruments et le vaisseau.
- POST /script/run : autorise l’exécution de scripts côté serveur. Les chercheurs décrivent aussi la possibilité d’utiliser une path traversal pour sortir du répertoire prévu.
- POST /seq : permet d’exécuter des séquences de commandes, avec une dérive possible vers des fichiers en dehors du répertoire attendu, lorsque des chemins sont passés à un sous-processus.
Cycode relie ces comportements à des catégories CWE : CWE-306, CWE-352 et CWE-22.
Le rôle des requêtes “simples” et du CSRF réel
Un point central dans le scénario d’attaque concerne le type de données envoyé au serveur. L’advisory indique que les endpoints acceptent des corps application/x-www-form-urlencoded. Or, dans le navigateur, ce format peut être traité comme une requête “simple”.
Selon les chercheurs, cela permet à un POST inter-origine d’atteindre l’endpoint sans prévol (OPTIONS). Ils soulignent donc que même un déploiement “local” ou derrière un pare-feu n’est pas forcément protecteur : l’utilisateur qui visite une page malveillante peut, depuis son navigateur, déclencher la requête vers le serveur.
Cycode indique que des captures de trafic réseau depuis un navigateur réel confirment l’arrivée du POST inter-origine avec zéro requête OPTIONS, et que le serveur le traite.
Ce que change AIT-GUI 2.5.2
Dans le changelog associé à AIT-GUI 2.5.2, le projet détaille les mesures prises pour réduire fortement l’exploitation via le navigateur.
Parmi les modifications, les chercheurs indiquent que la nouvelle version :
- lie l’hôte configuré et, par défaut, utilise localhost plutôt que d’écouter sur toutes les interfaces ;
- ajoute un before_request hook qui compare Origin ou Referer avec l’Host du serveur pour des méthodes sensibles (POST, PUT, DELETE, PATCH) ;
- contraint /script/run et /seq dans leurs racines configurées afin de limiter les chemins sortants.
Le projet précise que les endpoints modifiant l’état refusent désormais les requêtes navigateur cross-origin en se basant sur la vérification d’origine, ce qui vise directement le risque CSRF. En revanche, les clients non-browsers qui n’envoient pas ces en-têtes ne seraient pas impactés par cette vérification.
Session cookie : une subtilité relevée dans le code
Après examen de la source, The Hacker News (selon le dossier de référence) signale un autre aspect à considérer. Ils notent que, même dans la version 2.5.2, la racine appelle Sessions.create() et émet un cookie de session à une requête sans vérification de crédentiales.
Ils observent aussi que l’endpoint de commande accepte ensuite toute requête munie de ce cookie.
Cette découverte ne contredit pas automatiquement les changements visant le cross-origin navigateur, mais elle montre que la logique d’accès ne se résume pas à la seule couche CSRF : la manière dont la session est initiée et utilisée reste un élément clé de l’exposition.
Incertitude autour des versions et d’autres identifiants
Le dossier de référence évoque également l’existence d’un enregistrement séparé lié à la même absence d’authentification, référencé par CVE-2026-60112. Cet élément aurait été publié au National Vulnerability Database et dans la GitHub Advisory Database le 29 juillet 2026, soit environ trois semaines avant la publication de l’analyse Cycode.
Les informations de l’enregistrement CVE et celles de Cycode divergent toutefois sur le périmètre exact des versions corrigées. Selon le rapport, l’entrée VulnCheck et NVD mentionnerait un correctif basé sur un commit donné, en plaçant le défaut “avant 2.5.1”, tandis que l’advisory Cycode considère 2.5.1 comme affecté et 2.5.2 comme corrigé.
Le code du dépôt indiquerait que la création de session sans authentification persiste dans 2.5.1 et 2.5.2 selon les vérifications rapportées.
Enfin, le dossier cite le fait qu’aucune information de vulnérabilité n’apparaîtrait dans certaines données PyPI, et que l’aire exacte de couverture des identifiants (GHSA/CVE) ne serait pas alignée entre les différentes bases consultées.
Ce que cela signifie pour les équipes qui opèrent le logiciel
Au-delà du cas précis d’AIT-GUI, la leçon est claire. Une console web destinée à piloter des systèmes physiques doit être traitée comme une surface d’attaque critique : exposition réseau, contrôles d’accès, limitations de chemins et protections CSRF doivent être cohérents et testés ensemble.
Pour réduire le risque de AIT-GUI commandes abusives, la mise à jour vers la version 2.5.2 est explicitement mentionnée. En parallèle, il est essentiel de limiter l’exposition réseau : ne pas écouter sur des interfaces publiques, contrôler l’accès au port 8080 et vérifier les règles de pare-feu.
Enfin, il faut prêter attention à la façon dont les sessions sont créées et utilisées côté serveur, puisque les changements anti cross-origin ne suffisent pas à eux seuls si des endpoints acceptent des requêtes munies d’un jeton obtenu sans authentification robuste.
Conclusion
La publication de Cycode met en lumière une combinaison de faiblesses dans AIT-GUI qui peut conduire, dans certains scénarios, à des commandes arbitraires d’instruments et de vaisseaux via une interface web. L’attaque ne repose pas uniquement sur une erreur “technique” isolée : l’enchaînement passe par l’absence d’authentification, une exposition réseau large et un manque de protections contre les requêtes déclenchées depuis des pages tierces.
Heureusement, des corrections ont été introduites dans AIT-GUI 2.5.2, notamment via la restriction de l’adresse d’écoute et la validation d’origine pour les requêtes sensibles. Pour les opérateurs, la priorité reste la mise à jour et la réduction de l’exposition réseau afin de limiter drastiquement les possibilités d’attaque.
Source: https://thehackernews.com/2026/08/nasa-ait-gui-flaws-could-let.html
