Bei der browserbasierten Operator-Konsole AIT-GUI im Umfeld der NASA/JPL-Software AMMOS Instrument Toolkit sind AIT-GUI Sicherheitslücken bekannt geworden, die weitreichende Folgen haben können. Wie Cycode beschreibt, reicht ein nicht authentifizierter Zugriff auf den Webserver aus, um beliebige Kommandos an Instrumente und eine Kommando-Bus-Komponente zu senden.
Besonders kritisch ist dabei die Kombination aus fehlender Absicherung sensibler Endpunkte, ungünstig konfigurierten Netzwerkbindungen und Schwächen im Umgang mit Eingaben. Zwar wurde mit Version 2.5.2 eine Korrektur veröffentlicht, doch ältere Releases sind weiterhin betroffen.
Worum es bei AIT-GUI und AMMOS geht
Das AMMOS Instrument Toolkit dient als Framework zum Aufbau von Ground-Data-Systemen. Diese Software sendet Kommandos an Instrumente und Raumfahrzeuge und verarbeitet anschließend die Telemetriedaten, die vom Zielsystem zurückkommen.
AIT-GUI ist dabei die Operator-Konsole im Browser. Der entscheidende Punkt: Bestimmte Web-Endpunkte leiten Betreiberbefehle an eine Kommando-Bus-Schicht weiter, über die wiederum Instrumenten- und Raumfahrzeugkommandos ausgegeben werden können.
Bewertung und Status: hohe Schwere, kein zugehöriges CVE
Cycode ordnete die Schwachstellenkette unter der Kennung GHSA-p9r8-2q67-fp86 ein und bewertete sie mit 9,4 nach CVSS v3.1. Laut Advisory betrifft das Problem AIT-GUI Version 2.5.1 und früher. Ein Fix ist in 2.5.2 enthalten.
Wichtig für den Kontext: In der Cycode-Veröffentlichung wird angegeben, dass keine CVE zugeordnet wurde. Gleichzeitig existiert unabhängig davon ein weiterer Datensatz mit der Kennzeichnung CVE-2026-60112, der jedoch bei Details zur Abgrenzung und zum Patch abweichende Aussagen macht.
So entstehen die Angriffsmöglichkeiten
Die Advisory beschreibt mehrere Ursachen, die zusammen ein unsicheres Gesamtsystem ergeben. Dazu gehört zunächst, wie der AIT-GUI Webserver seine Zieladresse behandelt: Der konfigurierte Host-Wert wird laut Cycode nicht korrekt verwendet. Stattdessen lauscht der Server standardmäßig auf 0.0.0.0 auf Port 8080. Dadurch ist der Dienst aus dem Netzwerk erreichbar, wenn Port und Firewall-Umgebung es zulassen.
Darüber hinaus zeigt die Meldung, dass zustandsändernde Routen ohne ausreichende Absicherung ausgeliefert werden: keine Authentifizierung, keine Autorisierung und auch keine CSRF-Schutzmaßnahmen für die betroffenen Endpunkte.
Konkrete riskante Endpunkte: Befehle, Skripte, Sequenzen
Cycode nennt, was ein Angreifer ohne Anmeldung tun kann, sofern er den Port erreichen kann. Zu den beschriebenen Möglichkeiten gehören:
- POST /cmd: Ausgabe beliebiger Instrument- und Raumfahrzeugkommandos.
- POST /script/run: Ausführen von Server-seitigen Skripten, einschließlich Zugriff außerhalb des vorgesehenen Verzeichnisses durch Path Traversal.
- POST /seq: Starten von Kommando-Sequenzen, ebenfalls möglich mit Übergabe von Dateien außerhalb des Zielbereichs an einen Subprozess.
Cycode veranschaulicht den “Impact”, indem nicht von deface-artigen Seiteneffekten ausgegangen wird, sondern davon, dass sich die Auswirkung in ausgeführten Instrument- und Befehlsaktionen misst.
Warum CSRF in browserbasierten Szenarien besonders kritisch ist
Ein weiterer Punkt betrifft die Art der Anfrageformate: Da die betroffenen Routen application/x-www-form-urlencoded Bodies akzeptieren, gelten diese laut Advisory als “CORS einfache” Requests. Das kann zur Folge haben, dass ein Cross-Origin POST ohne Preflight beim Browser ankommt.
Praktisch bedeutet das: Selbst in einem Setup, das “host-local” betrieben wird oder durch Firewalls eingeschränkt ist, kann die Schwachstelle ausgenutzt werden, wenn ein Operator mit Browserzugriff eine Seite öffnet, die ein Angreifer kontrolliert. In den beschriebenen Tests wird sogar dokumentiert, dass im Mitschnitt des Netzwerkverkehrs keine OPTIONS-Preflight-Anfrage erfolgt und der Server die Requests verarbeitet.
Welche Schwachstellenklassifikationen genannt werden
Die Advisory ordnet die beobachteten Probleme u. a. folgenden Kategorien zu: CWE-306 (fehlende Authentifizierung), CWE-352 (fehlende Autorisierung) und CWE-22 (Path Traversal). Diese Einordnung passt zu den beschriebenen Endpunkten und zur unzureichenden Eingabevalidierung.
Was in AIT-GUI 2.5.2 geändert wurde
Mit der Veröffentlichung von AIT-GUI 2.5.2 am 12. August 2026 wurden mehrere Schutzmaßnahmen ergänzt. Laut Projekt-Change-Log werden insbesondere zwei Aspekte adressiert:
- Der Server bindet so, wie konfiguriert—standardmäßig wird localhost verwendet.
- Ein before_request-Hook prüft für POST, PUT, DELETE und PATCH anhand von Origin oder Referer gegen die eigene Host-Angabe, wodurch Cross-Origin Browseranfragen zurückgewiesen werden.
Außerdem werden /script/run und /seq laut Beschreibung stärker in ihre vorgesehenen Wurzeln eingegrenzt. Ziel ist, die Reichweite von Pfaden und die Ausführbarkeit außerhalb der erwarteten Verzeichnisse zu begrenzen.
Der Zusatz “State-changing endpoints” ist dabei wichtig: Die Maßnahme richtet sich explizit gegen browsergetriebene Cross-Origin Requests. Für nicht-browserbasierte Clients, die ohne die relevanten Header senden, bleibt es nach den Angaben im Changelog grundsätzlich anders bewertet.
Rechtsstreit um Details: Patch-Abgrenzung und widersprüchliche Datensätze
Nach Prüfung der Advisory stellte The Hacker News Unstimmigkeiten zwischen Datensätzen fest. Während VulnCheck und der NVD-Eintrag die betroffene Version “vor 2.5.1” einordnen und auf einen bestimmten Patch verweisen, nennt Cycode 2.5.1 als betroffen und 2.5.2 als behoben.
Gleichzeitig soll laut Repository-Auswertung die unautorisierte Sitzungserstellung in beiden Versionen vorhanden sein: In der Untersuchung heißt es, dass das Wurzel-Routing weiterhin Sessions.create() aufruft und ein Sitzungscookie an Requests ausgibt, ohne eine Credential-Prüfung vorzunehmen. Der Kommando-Endpunkt akzeptiert demnach Requests, die dieses Cookie enthalten.
Die Diskussion betrifft damit weniger die Existenz von Schwächen, sondern insbesondere wie der Fix in öffentlich dokumentierten Quellen zusammengefasst wurde—und in welchen Versionen welche Teilaspekte als “geheilt” gelten.
Was Betreiber jetzt tun sollten
Auch ohne konkrete Ausnutzung durch öffentliche Berichte gilt: Wenn eine Operator-Konsole Befehle an Raumfahrzeug- oder Instrument-Komponenten vermittelt, müssen Webzugriffe besonders restriktiv abgesichert werden. Aus den beschriebenen Punkten folgen vor allem operative Schritte:
- Upgrade auf AIT-GUI 2.5.2 oder eine neuere, bestätigte Version.
- Netzwerkbindung prüfen: Services nicht unnötig auf 0.0.0.0 exponieren.
- Endpunkte und CSRF-/CORS-Verhalten überprüfen, insbesondere für Zustandsänderungen.
- Rechte- und Sitzungslogik validieren, damit Sessions nicht ohne echte Authentisierung ausgestellt oder für Befehle missbraucht werden können.
Kein Bericht über echte Angriffe – aber ein klares Risikoprofil
Die Advisory und die ergänzende Berichterstattung nennen keine konkreten Hinweise auf ausgeführte Angriffe gegen eine Mission, und beide Datensätze berichten nicht über beobachtete Exploits. Dennoch ist das Risikoprofil hoch: Ein Angreifer benötigt lediglich Netzwerkkonnektivität zum Port und kann dann über HTTP Requests die beschriebenen Endpunkte ansteuern.
Damit zeigt sich erneut, wie gefährlich “Operator-Guic” werden können, wenn sie statt strikter Authentisierung und Zugriffskontrollen primär auf Bedienbarkeit ausgelegt sind—insbesondere, wenn browserbasiertes Verhalten (CORS, Preflight, Request-Typen) zu überraschenden Angriffswegen führt.
Fazit: AIT-GUI Sicherheitslücken ernst nehmen
Die AIT-GUI Sicherheitslücken drehen sich im Kern um fehlende Authentifizierung und Autorisierung für sicherheitsrelevante Endpunkte sowie zusätzlich um Schwächen bei der Handhabung von Pfaden und requestbezogenen Schutzmechanismen. Mit AIT-GUI 2.5.2 wurden wichtige Gegenmaßnahmen eingeführt, etwa gegen Cross-Origin Requests und für die Begrenzung sensibler Skript- und Sequenzbereiche.
Für Betreiber gilt: Aktualisieren, Exposition reduzieren und die Absicherung der Befehlswege konsequent prüfen. Gerade weil die Konsole Befehle in der realen Betriebsumgebung anstoßen kann, sollte das Sicherheitsniveau nicht “halb” umgesetzt werden.
Quelle: https://thehackernews.com/2026/08/nasa-ait-gui-flaws-could-let.html
