Critical Vulnerability in NASA/JPL’s AIT-GUI: Commands and Scripts Exposed Without Authentication

The flaw affects the AMMOS operations console

On August 22, 2026, a critical vulnerability was disclosed in AIT-GUI, a component of the AMMOS Instrument Toolkit, an open-source framework developed by NASA/JPL for multi-mission operations.

AIT-GUI provides operators with a browser-based console. Through this interface, they can interact with scientific instruments and spacecraft, send commands, execute sequences, and collect data returned by the systems under control.

The vulnerability is tracked as GHSA-p9r8-2q67-fp86. It has a Critical severity rating and a CVSS score of 9.4. A fix is available in AIT-GUI 2.5.2.

The vulnerable versions have not been disclosed in detail. Installations that have not been upgraded to the fixed release should therefore be considered at risk until the update has been verified.

Server exposed on all network interfaces

According to Cycode’s analysis, AIT-GUI starts an HTTP server without authentication, authorization, session management, or protection against Cross-Site Request Forgery (CSRF) attacks.

The issue is not limited to the absence of a login mechanism. The application reads the host configuration but does not use it to determine the service’s listening address. Instead, the server binds to:

0.0.0.0

This makes the service reachable through all available network interfaces. As a result, even a configuration such as host: localhost, which should restrict access to the local machine, does not prevent exposure to networks reachable by the instance.

An attacker who can reach the service port can interact directly with operational routes. An account may not be required.

Endpoints enable commands, sequences, and scripts

The most sensitive endpoint is:

POST /cmd

The value supplied in the command field is interpreted and forwarded directly to the command bus. In the flow described by Cycode, there is no authentication, validation, or sufficient intermediary control to prevent arbitrary commands from being sent.

Other operational endpoints are also exposed:

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

The /seq and /script/run routes construct file paths by concatenating user-controlled input with the application’s configured root directory. The paths are not consistently confined.

An input such as:

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

can therefore resolve outside the authorized directory. This creates a path traversal scenario, potentially allowing access to files elsewhere in the filesystem or execution of scripts not intended by the operator.

The codebase already contains logic designed to prevent escaping the permitted directory. However, according to the researchers, the check is applied to /scripts/load and has not been consistently reused for /seq and /script/run.

The risk remains even behind a firewall

An exposed installation could allow an attacker to:

• send arbitrary commands to instruments or spacecraft through /cmd;
• execute sequences through /seq;
• launch server-side scripts with /script/run;
• attempt to access files outside the intended directory using manipulated paths.

The lack of CSRF protections further expands the attack surface. An operator using AIT-GUI in a browser could visit a malicious page or follow a harmful link within the same environment.

The malicious page could cause the browser to send requests to the console. Under certain conditions, these requests may be sent without a preliminary check with the target service, effectively bypassing the expectation that an operational request must originate from the legitimate interface.

A firewall is therefore not sufficient protection. If the operator’s browser can reach AIT-GUI and loads malicious content, the attack may succeed without the attacker having direct, interactive access to the console port.

The lack of authentication also makes it difficult to attribute each command to a specific user. Installations exposed before the fix should be treated as potentially compromised, even if no obvious errors are immediately apparent.

The analysis produced working exploit demonstrations

Cycode combined AI-assisted code analysis with manual verification. The automated tools searched, among other things, for routes capable of changing state without authentication, request data passed to subprocesses without sanitization, and configuration values that were read but subsequently ignored.

The researchers then reproduced the identified issues in an operational environment. This work resulted in working proof-of-concept exploits, including a CSRF demonstration performed with a real headless browser.

During the test, zero network preflights were recorded. This shows that the scenario does not necessarily depend on prior authorization by the exposed service: a browser can send certain cross-origin requests without performing the preliminary check normally associated with more restrictive requests.

Cycode considers vulnerabilities that were reproduced operationally confirmed, distinguishing them from findings that emerged solely from static code analysis.

What administrators should do

The primary measure is to immediately upgrade every installation to AIT-GUI 2.5.2. Restricting access through a firewall alone should not be considered a permanent solution.

Administrators should also:

1. verify that the console port is not reachable from untrusted networks;
2. review logs for commands, sequences, and scripts executed before the upgrade;
3. investigate every exposed instance as potentially compromised;
4. add authentication and CSRF protections to /cmd, /seq, and /script/run;
5. ensure that the server actually uses the configured host instead of binding to 0.0.0.0;
6. apply the same path-confinement logic already present in /scripts/load to /seq and /script/run.

It is not known whether GHSA-p9r8-2q67-fp86 has been added to CISA’s KEV catalog, nor is there any information about operational deadlines set by the agency. No recent entries from the same vendor are currently listed in the catalog.