NASA lab console flaw allows unauthorised commands

Cycode researcher Yuval Elbar identified a critical vulnerability in NASA Jet Propulsion Labouratory's open-source AIT-GUI software. The flaw affected the browser-based console used to command spacecraft and scientific instruments.

The issue has been fixed in AIT-GUI version 2.5.2 and is tracked as GHSA-p9r8-2q67-fp86 with a CVSS score of 9.4.

AIT-GUI is the web interface for the AMMOS Instrument Toolkit, an open-source framework used in ground data systems that send commands to instruments and spacecraft and process the telemetry returned. Elbar found that the software exposed state-changing endpoints without authentication, authorization, or cross-site request forgery protection, creating a path to unauthorized command execution.

According to the research, an attacker with network access to the software could issue arbitrary commands through a POST request to the /cmd endpoint. Other endpoints could also be used to run server-side scripts and execute command sequences without credentials.

The research also identified a network exposure issue in the server configuration. Although users could define a host setting, the server was hardcoded to listen on 0.0.0.0, meaning it bound to all network interfaces instead of remaining limited to localhost.

As a result, operators who believed the console was restricted to loopback access may actually have exposed it to any reachable network. The software runs on port 8080 by default.

How it worked

The vulnerability combined several separate weaknesses. Elbar said there was no login requirement, no session check, and no CSRF token on state-changing routes, while form submissions accepted by the software could be sent cross-origin by a browser without preflight checks.

This created a second attack path beyond direct network access. Even if the system sat behind a firewall or was configured for host-local use, a malicious web page visited by an operator could potentially send commands to the interface from the operator's browser.

The research also found path traversal issues in endpoints used for scripts and sequences. User-supplied input was joined to filesystem paths without sufficient validation, which could allow files outside the intended directories to be invoked.

In one case, the /seq endpoint checked only whether a resulting file existed before passing it to a subprocess. In another, the /script/run route followed a similar pattern, despite a stronger path-confinement check already existing elsewhere in the codebase.

Operational risk

The significance of the bug lay in the software's role. AIT-GUI is not a conventional consumer web application but an operator console tied to systems that issue commands to hardware, making the consequences of unauthorized requests more serious than in many other web security cases.

"A web GUI used to drive spacecraft and instrument commanding shipped a server that listens on every network interface, asks nobody for a password, and can be steered by any web page an operator happens to open. Here is how a stack of small, ordinary web mistakes adds up to unauthenticated command execution against hardware that is very much not ordinary, and what to do about it," said Yuval Elbar, Security Researcher, Cycode.

Elbar said the vulnerabilities did not depend on advanced exploitation methods. "No step requires a memory-corruption primitive, an auth bypass, or a novel exploit technique. It is four well-understood web weaknesses composed against a very high-value target," he said.

Fix and mitigation

Users are advised to upgrade to AIT-GUI 2.5.2 or later and ensure the console port is not reachable from untrusted networks. Operators should also review command and sequence history if the system may previously have been exposed.

Additional hardening measures include adding authentication and authorization to all state-changing endpoints, introducing CSRF protections, binding the server to the configured host rather than all interfaces, and validating script and sequence paths so they cannot escape intended directories.

Elbar also described how the vulnerability was discovered, saying AI-assisted code analysis helped surface suspicious patterns in the codebase before manual validation confirmed exploitability. "A lead is not a finding. The step that matters is validation: every issue above was confirmed by hand and reduced to a working proof of concept, including the self-contained CSRF demonstration that drives a real headless browser and records zero preflights. A pattern match tells you where to look; a reproduced exploit tells you it's real. We only report the second kind," he said.