The AMMOS Instrument Toolkit GUI (AIT-GUI) is an open-source browser-based operator console developed by NASA's Jet Propulsion Laboratory (JPL) as part of the Advanced Multi-Mission Operations System (AMMOS) Instrument Toolkit (AIT). It serves as the primary human interface for commanding spacecraft and scientific instruments, translating operator button clicks into commands relayed to the AIT command bus and ultimately to flight hardware. AIT is used across multiple NASA missions for ground data system (GDS) operations, telemetry monitoring, and spacecraft commanding. The AIT framework uses a modular ZeroMQ-based server architecture with inbound/outbound streams, handlers, and plugins, where AIT-GUI functions as a plugin providing a web-based REST API with Server-Sent Events for real-time telemetry.

Security researcher Yuval Elbar of Cycode discovered a critical vulnerability (GHSA-p9r8-2q67-fp86, CVSS 9.4, published August 13, 2026) comprising four distinct but compounding web application weaknesses in AIT-GUI versions through 2.5.1.

First, the AIT-GUI web server reads its configured host setting but silently discards it, hardcoding the listener to bind on 0.0.0.0 across all network interfaces on port 8080 (default) — a mission operator who configures host: localhost for loopback-only access inadvertently exposes the console to the entire reachable network, including potentially the internet depending on firewall rules. The vulnerable code in ait/gui/__init__.py reads host = getattr(self, 'host', 'localhost') then immediately discards it, constructing the WSGIServer with ("0.0.0.0", port).

Second, none of the application's state-changing routes enforce authentication, authorization, or CSRF protections. There is no login requirement, no session gate, no CSRF token, and no CORS restriction on any route. All state-changing endpoints accept application/x-www-form-urlencoded request bodies — a content type that browsers treat as CORS "simple" requests deliverable cross-origin without a preflight OPTIONS handshake.

Third, the POST /cmd endpoint (ait/gui/__init__.py line ~369) reads the command field from bottle.request.forms, splits it into arguments, uppercases the first token, and passes them directly to self.send() — which relays the command to the spacecraft command bus with zero validation of the command name, arguments, or sender authority.

Fourth, the POST /script/run and POST /seq endpoints (line ~1023) construct filesystem paths from unvalidated user input. The /seq endpoint joins bn_seqfile = bottle.request.forms.get("seqfile") to SEQRoot via os.path.join with no confinement — only an os.path.isfile check exists — then spawns a subprocess via gevent.subprocess.Popen(["ait-seq-send", seqfile], ...). Similarly, /script/run joins scriptPath to ScriptRoot without confinement checks. Notably, a correct path-confinement check already existed on the /scripts/load endpoint in the same codebase but was not reused on /seq or /script/run, exemplifying an inconsistent security posture within the same module.

A separately tracked related flaw, CVE-2026-60112 (CVSS 9.8 v3.1 / 9.3 v4.0), was published on July 28, 2026, and disclosed by Saidakbarxon Maxsudxonov via VulnCheck. This flaw describes a missing authentication vulnerability in the Sessions.create() endpoint (CWE-306), which performs no credential validation whatsoever. Any unauthenticated network attacker can call Sessions.create() to obtain a valid session, then invoke handle_cmd() to forward arbitrary commands directly to the AIT command bus with no authentication gate between session creation and command dispatch. This flaw is fixed in AIT-GUI 2.5.1 (commit beb8fc0, authored by Rat5ak), while the broader four-issue advisory is fixed in version 2.5.2.

Because the endpoints accept application/x-www-form-urlencoded request bodies, even a host-local or firewalled AIT-GUI deployment is exploitable via cross-site request forgery (CSRF, CWE-352). If a mission operator with AIT-GUI open in their browser visits a malicious webpage, that page can silently submit a self-submitting HTML form to POST http://127.0.0.1:8080/cmd with command=NO_OP 1 2 3 — the browser delivers the request cross-origin without a preflight check, and the server executes it without a CSRF token or origin validation. This means no direct network connectivity to the AIT-GUI port is required for the CSRF attack vector; only the operator's browser access to the console is needed.

Practical proof-of-concept commands published in the disclosure demonstrate exploitation with basic curl against any reachable target: - curl -i -X POST http://TARGET:8080/cmd --data-urlencode 'command=NO_OP 1 2 3' - curl -i -X POST http://TARGET:8080/script/run --data-urlencode 'scriptPath=../../../../path/to/any/script' - curl -i -X POST http://TARGET:8080/seq --data-urlencode 'seqfile=../../../../path/to/any/file'

The discovery methodology combined human researcher judgment with AI-assisted code analysis. The tool surfaced suspicious patterns across the codebase — routes with no auth decorators, tainted request.forms input flowing into dangerous sinks (os.path.join then subprocess.Popen), dead configuration writes where host was assigned then discarded, and unused safe patterns (the /scripts/load confinement check that /seq and /script/run failed to reuse). Each finding was confirmed by hand and reduced to a working proof-of-concept, including a self-contained CSRF demonstration using a real headless browser. As Yuval Elbar stated: "A pattern match tells you where to look; a reproduced exploit tells you it's real."

At the time of disclosure (August 2026), no active exploitation in the wild has been publicly confirmed. CISA's SSVC assessment for CVE-2026-60112 classifies the flaw as automatable with total technical impact, though exploitation status is listed as "none." The CISA Known Exploited Vulnerabilities (KEV) catalog does not include this CVE. The EPSS score of 0.408% (34th percentile) suggests growing awareness. The advisory affects 20+ industries that may use AIT-GUI or its parent AIT framework, including aerospace, defense, research institutions, and government agencies operating spacecraft ground systems.

Remediation requires upgrading to AIT-GUI 2.5.2 (pip install ait-gui==2.5.2), auditing command and sequence history for any pre-patch unauthorized activity, and confirming the console port is not reachable from untrusted networks. NASA-AMMOS released 2.5.2 on August 12, 2026, with durable fixes: authentication and authorization on all state-changing endpoints, CSRF protection either via tokens or rejecting CORS-simple content types, binding to the configured host (defaulting to localhost) instead of hardcoded 0.0.0.0, and path confinement using os.path.realpath canonicalization with is_relative_to checks to verify resolved paths stay within intended root directories. Earlier hardening in version 2.5.0-rc1 had already removed Python's pickle module (a known vector for arbitrary code execution during deserialization) and added some path handling improvements via SonarQube-recommended changes, but these were insufficient to prevent the discovered flaws.

This case underscores a critical gap in operational technology (OT) and space cybersecurity: ground-system and mission operations software inherits the same web application weaknesses as ordinary enterprise software, but the cost of a successful exploit is measured in real-world hardware actions against spacecraft and scientific instruments rather than data breaches. Four ordinary web flaws — no authentication, no CSRF protection, path traversal, and a network configuration error — compose into an exploit chain that threatens active space missions. The vulnerability is particularly significant because AIT is open-source software used across multiple NASA and partner missions, making the attack surface potentially broader than a single proprietary system.