NASA AIT-GUI: Kette kritischer Schwachstellen ohne wirksame Authentifizierung

Sicherheitsforscher des Unternehmens Cycode haben eine Kette von Schwachstellen offengelegt in AIT-GUI – einer browserbasierten Operator-Konsole für das Open-Source-Framework AMMOS Instrument Toolkit (NASA/JPL), das für den Aufbau von Bodensystemen zur Steuerung von Raumfahrzeugen und Instrumenten vorgesehen ist. Die Kette, nachverfolgt als GHSA-p9r8-2q67-fp86 mit einem Score von 9,4 nach CVSS v3.1, ermöglicht es einem nicht authentifizierten Angreifer, beliebige Kommandos auf den Befehlsbus der Software zu schicken. Betroffen sind Version 2.5.1 und älter; als behoben gilt das Problem laut Angaben in Version 2.5.2, doch eine Analyse des Quellcodes zeigt, dass auf den zentralen Endpunkten weiterhin keine Authentifizierung vorhanden ist. Fälle einer Ausnutzung unter realen Bedingungen sind derzeit nicht bekannt.

Technische Details der Schwachstellen

Nach Angaben der Forscher liest der Webserver von AIT-GUI den konfigurierten Host-Wert ein, ignoriert ihn aber anschließend und bindet den Listener fest an die Adresse 0.0.0.0 auf Port 8080. Das bedeutet, dass der Server Verbindungen über sämtliche Netzwerkschnittstellen annimmt. Gleichzeitig sind alle Routen, die den Systemzustand verändern, ohne Authentifizierung, Autorisierung und Schutz vor Cross-Site Request Forgery (CSRF) erreichbar.

Die Schwachstellen sind in drei CWE-Kategorien eingeordnet:

• CWE-306 – fehlende Authentifizierung für kritische Funktionen
• CWE-352 – Cross-Site Request Forgery
• CWE-22 – Pfadumgehung (Path Traversal)

Ein nicht authentifizierter Angreifer mit Netzwerkzugriff auf den Port kann:

• beliebige Kommandos an Instrumente und Raumfahrzeuge über POST /cmd senden
• Server-Skripte über POST /script/run starten, einschließlich von Dateien außerhalb des erlaubten Verzeichnisses mittels Pfadumgehung
• Befehlssequenzen über POST /seq ausführen, indem Dateien aus beliebigen Verzeichnissen an den Subprozess übergeben werden

Besonders kritisch ist der Angriffsvektor über CSRF. Da die Routen Request-Bodies im Format application/x-www-form-urlencoded akzeptieren, werden sie von Browsern als „simple“ CORS-Requests eingestuft und ohne vorherigen OPTIONS-Preflight gesendet. Wie die Forscher berichten, wird ein Cross-Site-POST-Request an den Server übermittelt und dort verarbeitet, sobald ein Operator mit Zugriff auf die Konsole im Browser eine von einem Angreifer kontrollierte Seite öffnet – selbst wenn die Konsole hinter einer Firewall betrieben wird.

Unvollständige Behebung in Version 2.5.2

Die Version AIT-GUI 2.5.2 wurde am 12. August 2026 veröffentlicht. Laut Changelog wurden drei zentrale Verbesserungen umgesetzt:

• Bindung an den konfigurierten Host (Standard nun localhost statt 0.0.0.0)
• Prüfung von Origin/Referer gegen Host für POST-, PUT-, DELETE- und PATCH-Requests zum Schutz vor CSRF
• Einschränkung der Routen /script/run und /seq auf konfigurierte Wurzelverzeichnisse

Die Analyse des Quellcodes von Version 2.5.2 zeigte jedoch, dass auf den Endpunkten für Kommandos, Skripte und Sequenzen keine Authentifizierung ergänzt wurde. Die Root-Route ruft weiterhin Sessions.create() auf und gibt jedem Request ohne Prüfung von Zugangsdaten ein Session-Cookie aus, und die Kommando-Route akzeptiert jede Anfrage mit diesem Cookie. Das Update reduziert damit zwar die Angriffsfläche, beseitigt aber nicht das grundlegende Problem des fehlenden Authentifizierungsmechanismus.

Widersprüchliche Schwachstellenmeldungen

Die Lage wird zusätzlich durch das Vorhandensein eines parallelen Eintrags zur Schwachstelle verkompliziert. CVE-2026-60112, bewertet mit 9,3 nach CVSS v4 und veröffentlicht am 29. Juli 2026 – drei Wochen vor dem Bericht von Cycode –, beschreibt denselben Defekt der fehlenden Authentifizierung. Allerdings unterscheiden sich die Angaben zu den betroffenen Versionen: VulnCheck und der NVD-Eintrag geben an, dass die Schwachstelle Versionen bis 2.5.1 betrifft und verweisen auf den Commit beb8fc0 als Patch, während Cycode 2.5.1 als verwundbar einstuft und 2.5.2 als behobene Version nennt. Die Analyse des Quellcodes beider Versionen zeigt jedoch, dass die nicht authentifizierte Ausgabe von Sessions sowohl in 2.5.1 als auch in 2.5.2 vorhanden ist.

Darüber hinaus könnte ein Teil des im Cycode-Bericht behaupteten Umfangs der Schwachstelle übertrieben sein: Die Analyse des Quellcodes von Version 2.5.1 ergab, dass die Route /script/run bereits eine Kanonisierung und Tiefenprüfung des Pfads enthält – genau jene Maßnahmen, die der Bericht selbst empfiehlt. Eine unbeschränkte Pfadkonstruktion in 2.5.1 existiert nur auf der Route /seq.

Problem der Verteilung über PyPI

Ein besonders kritischer Aspekt: Die letzte Version des Pakets ait-gui auf PyPI ist 2.4.1, hochgeladen am 27. Juli 2023. Die Versionen 2.5.0, 2.5.1 und 2.5.2 tauchen in der Release-Historie von PyPI nicht auf. Das bedeutet, dass Nutzer, die das Paket per pip installieren, eine Version erhalten, die fest an 0.0.0.0 gebunden ist und auf beiden Routen eine unbeschränkte Pfadkonstruktion aufweist. Gleichzeitig zeigt PyPI für dieses Paket keine Informationen zu Schwachstellen an, und keiner der Schwachstelleneinträge ist in das System Dependabot integriert.

Größerer Sicherheitskontext der NASA-Boden-Software

AIT-GUI ist nicht die einzige Komponente der NASA-Boden-Software mit ungeklärten Sicherheitsproblemen. In der GitHub Advisory-Datenbank finden sich Hinweise auf mehrere Schwachstellen in verwandten Projekten, darunter eine Pfadumgehung im AMMOS Instrument Toolkit (CVE-2026-47731), kritische Schwachstellen im Sequencing-Server NASA-AMMOS Aerie/PlanDev (CVE-2026-71214) sowie in der Referenzimplementierung des Asynchronous Network Management System (CVE-2026-71289).

Besondere Aufmerksamkeit verdient CVE-2024-35058 – eine kritische Remote-Code-Execution-Schwachstelle in der API-Funktion wait der Bibliothek NASA AIT-Core, veröffentlicht im Mai 2024. Sie betrifft Versionen bis einschließlich 2.5.2, und im Eintrag in der GitHub Advisory Database ist nach wie vor vermerkt, dass keine gepatchten Versionen verfügbar sind.

Empfehlungen

Organisationen, die AIT-GUI einsetzen, sollten folgende Maßnahmen ergreifen:

• Unverzüglich prüfen, ob Port 8080 von AIT-GUI aus nicht vertrauenswürdigen Netzen erreichbar ist, und den Zugriff durch Netzsegmentierung einschränken
• Ein Update auf Version 2.5.2 aus dem GitHub-Repository durchführen (nicht über PyPI, wo die aktuelle Version nicht verfügbar ist), in dem Bewusstsein, dass dies das Risiko reduziert, aber nicht vollständig beseitigt
• Einen Reverse-Proxy mit vollwertiger Authentifizierung vor AIT-GUI platzieren, da der Server selbst keine Zugangsdatenprüfung implementiert
• Den Zugriff von Konsolen-Operatoren auf externe Webressourcen einschränken, um das Risiko von CSRF-Angriffen zu minimieren
• Bereitgestellte AIT-Core-Instanzen im Hinblick auf CVE-2024-35058 prüfen, für die kein Patch verfügbar ist

Die Situation rund um AIT-GUI verdeutlicht ein systemisches Problem: Software zur Steuerung kritischer Weltrauminfrastruktur, die ursprünglich für isolierte Umgebungen entwickelt wurde, erweist sich als verwundbar, sobald sich das Bereitstellungsmodell ändert. Widersprüche zwischen Schwachstellenmeldungen, das Fehlen aktueller Versionen auf PyPI und die unvollständige Behebung in 2.5.2 bedeuten, dass derzeit die einzige verlässliche Schutzmaßnahme darin besteht, vor allen AIT-GUI-Instanzen eine externe Authentifizierungsschicht zu platzieren – unabhängig von der installierten Version.