Kritische Schwachstelle in der NASA/JPL-AIT-GUI: Befehle und Skripte ohne Authentifizierung offengelegt

Die Lücke betrifft die AMMOS-Betriebskonsole

Am 22. August 2026 wurde eine kritische Schwachstelle in der Komponente AIT-GUI des AMMOS Instrument Toolkit veröffentlicht, eines von NASA/JPL entwickelten Open-Source-Frameworks für missionsübergreifende Operationen.

AIT-GUI stellt Bedienern eine browserbasierte Konsole bereit. Über diese Oberfläche können sie mit wissenschaftlichen Instrumenten und Raumfahrzeugen interagieren, Befehle senden, Sequenzen ausführen und die von den kontrollierten Systemen zurückgegebenen Daten abrufen.

Die Schwachstelle trägt die Kennung GHSA-p9r8-2q67-fp86. Sie wurde mit dem Schweregrad Critical und einem CVSS-Score von 9.4 bewertet. Eine Fehlerbehebung ist in AIT-GUI 2.5.2 verfügbar.

Die betroffenen Versionen wurden nicht detailliert veröffentlicht. Installationen, die nicht auf die korrigierte Version aktualisiert wurden, sollten daher bis zur Überprüfung des Updates als gefährdet gelten.

Server auf allen Netzwerkschnittstellen erreichbar

Laut einer Analyse von Cycode startet AIT-GUI einen HTTP-Server ohne Authentifizierung, Autorisierung, Sitzungsverwaltung oder Schutz vor Cross-Site Request Forgery-Angriffen, kurz CSRF.

Das Problem beschränkt sich nicht auf das fehlende Login. Die Host-Konfiguration wird zwar von der Anwendung eingelesen, anschließend jedoch nicht zur Bestimmung der Adresse verwendet, auf der der Dienst lauscht. Stattdessen bindet sich der Server an:

0.0.0.0

Dadurch ist der Dienst über alle verfügbaren Netzwerkschnittstellen erreichbar. Selbst eine Konfiguration wie host: localhost, die den Zugriff eigentlich auf den lokalen Rechner beschränken sollte, verhindert somit nicht die Erreichbarkeit über das Netzwerk der jeweiligen Instanz.

Ein Angreifer, der den Service-Port erreichen kann, kann direkt mit den operativen Routen interagieren. Ein Benutzerkonto ist dafür nicht zwingend erforderlich.

Endpunkte ermöglichen Befehle, Sequenzen und Skripte

Besonders kritisch ist der Endpunkt:

POST /cmd

Der im Feld command enthaltene Wert wird interpretiert und direkt an den Befehlsbus weitergeleitet. In dem von Cycode beschriebenen Ablauf gibt es offenbar keine ausreichende Authentifizierung, Validierung oder zwischengeschaltete Kontrolle, die das Senden beliebiger Befehle verhindert.

Auch weitere Endpunkte mit operativen Funktionen sind betroffen:

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

Die Routen /seq und /script/run erzeugen Dateipfade, indem sie benutzergesteuerte Eingaben mit dem von der Anwendung vorgesehenen Stammverzeichnis verknüpfen. Eine konsistente Pfadbegrenzung fehlt.

Eine Eingabe wie:

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

kann dadurch außerhalb des autorisierten Verzeichnisses aufgelöst werden. Dies ermöglicht Path Traversal und damit potenziell den Zugriff auf Dateien in anderen Bereichen des Dateisystems oder die Ausführung von Skripten, die nicht vom Bediener vorgesehen waren.

Die Codebasis enthält bereits eine geeignete Logik, um das Verlassen des erlaubten Verzeichnisses zu verhindern. Nach Angaben der Forscher wird diese Prüfung jedoch nur auf die Route /scripts/load angewendet und nicht einheitlich für /seq und /script/run genutzt.

Das Risiko bleibt auch hinter einer Firewall bestehen

Eine exponierte Installation kann einem Angreifer ermöglichen:

• über /cmd beliebige Befehle an Instrumente oder Raumfahrzeuge zu senden;
• über /seq Sequenzen auszuführen;
• mit /script/run serverseitige Skripte zu starten;
• durch manipulierte Pfade auf Dateien außerhalb des vorgesehenen Verzeichnisses zuzugreifen.

Das Fehlen von CSRF-Schutz erweitert die Angriffsfläche zusätzlich. Ein Bediener, der AIT-GUI in seinem Browser verwendet, könnte eine schädliche Webseite besuchen oder einem manipulierten Link folgen.

Die präparierte Seite könnte den Browser dazu bringen, Anfragen an die Konsole zu senden. Unter bestimmten Bedingungen können diese Anfragen ohne vorherige Prüfung durch den Zielservice übertragen werden. Damit wird die Erwartung umgangen, dass eine operative Anfrage ausschließlich von der legitimen Oberfläche erzeugt werden darf.

Eine Firewall stellt daher keinen ausreichenden Schutz dar. Wenn der Browser des Bedieners AIT-GUI erreichen kann und schädliche Inhalte lädt, kann der Angriff auch ohne direkten interaktiven Zugriff des Angreifers auf den Konsolen-Port erfolgen.

Die fehlende Authentifizierung erschwert außerdem die Zuordnung einzelner Befehle zu bestimmten Benutzern. Installationen, die vor der Behebung exponiert waren, sollten als potenziell kompromittiert betrachtet werden, selbst wenn zunächst keine sichtbaren Fehler auftreten.

Die Analyse lieferte funktionierende Exploit-Nachweise

Cycode kombinierte eine KI-gestützte Codeanalyse mit manueller Überprüfung. Die automatisierten Werkzeuge suchten unter anderem nach Routen, die ohne Authentifizierung den Systemzustand verändern können, nach Anforderungsdaten, die ohne Bereinigung an Subprozesse weitergegeben werden, sowie nach eingelesenen, aber anschließend ignorierten Konfigurationen.

Anschließend reproduzierten die Forscher die festgestellten Auffälligkeiten unter realen Bedingungen. Dabei entstanden funktionsfähige Proofs of Concept, darunter eine CSRF-Demonstration mit einem tatsächlichen Headless-Browser.

Während dieses Tests wurden null Netzwerk-Preflights registriert. Das zeigt, dass dieses Szenario nicht zwingend von einer vorherigen Freigabe durch den exponierten Dienst abhängt: Der Browser kann bestimmte Cross-Origin-Anfragen übertragen, ohne die Vorabprüfung durchzuführen, die normalerweise mit restriktiveren Anfragen verbunden ist.

Cycode betrachtet die operativ reproduzierten Schwachstellen als bestätigt und unterscheidet sie von Ergebnissen, die ausschließlich aus der statischen Codeanalyse hervorgehen.

Was Administratoren tun sollten

Die wichtigste Maßnahme besteht darin, jede Installation umgehend auf AIT-GUI 2.5.2 zu aktualisieren. Eine bloße Zugriffsbeschränkung durch eine Firewall sollte nicht als dauerhafte Lösung betrachtet werden.

Administratoren sollten außerdem:

1. prüfen, dass der Konsolen-Port aus nicht vertrauenswürdigen Netzwerken nicht erreichbar ist;
2. Protokolle zu vor dem Update ausgeführten Befehlen, Sequenzen und Skripten überprüfen;
3. jede exponierte Instanz als potenziell kompromittiert untersuchen;
4. Authentifizierung und CSRF-Schutz für /cmd, /seq und /script/run implementieren;
5. sicherstellen, dass der Server den konfigurierten Host tatsächlich verwendet, anstatt an 0.0.0.0 zu binden;
6. dieselbe bereits in /scripts/load vorhandene Pfadbegrenzung auch auf /seq und /script/run anwenden.

Es ist nicht bekannt, ob GHSA-p9r8-2q67-fp86 in den KEV-Katalog der CISA aufgenommen wurde oder ob die Behörde operative Fristen festgelegt hat. Auch zu jüngeren Einträgen desselben Herstellers im Katalog liegen keine Angaben vor.