Cycode researchers disclosed a critical vulnerability — scored CVSS 9.4 — in AIT-GUI, the browser-based operator console that ships with NASA/JPL's open-source AMMOS Instrument Toolkit (AIT). The finding is as severe as it is simple: AIT-GUI shipped with no authentication, no session validation, and no CSRF protection on any of its state-changing endpoints. Any actor with network reachability to the console could send commands directly to spacecraft instruments and test articles — no credentials, no exploit chain, just an HTTP request.
If you're thinking "we don't operate spacecraft, so this doesn't apply to us" — think again. AIT is used beyond JPL. University CubeSat programs, aerospace research labs, defense contractors, and ground-station-as-a-service providers build on the AMMOS toolkit. More importantly, this incident is a textbook case study of a pattern we see constantly in operational technology and engineering environments: mission-critical tooling treated as an internal convenience app and deployed wide open. The defensive lessons here apply to every organization running bespoke web consoles against sensitive back ends.
This post breaks down what happened, how to hunt for exposure, and how to harden any deployment of AIT-GUI or comparable operator consoles.
Technical Analysis
What is affected
- Product: AIT-GUI, the web front end of the AMMOS Instrument Toolkit (AIT), an open-source ground data system developed by NASA's Jet Propulsion Laboratory for commanding and monitoring instruments and spacecraft.
- Affected component: The AIT-GUI web server itself — a Python-based HTTP service exposing endpoints that handle command dispatch, telemetry viewing, and instrument control.
- Severity: CVSS 9.4 (Critical). The score reflects unauthenticated remote exploitation with direct impact on the integrity and availability of the controlled system.
- Platforms: Any host running an unpatched AIT-GUI instance — typically Linux ground-station servers, lab workstations, or VM appliances reachable from engineering networks (and, in worst cases, the internet).
No CVE identifier has been published in the reporting to date; track the NASA/JPL AMMOS GitHub repositories and the Cycode disclosure for formal assignment.
How the vulnerability works
The failure is a classic CWE-306 (Missing Authentication for Critical Function) combined with CWE-352 (CSRF):
- No authentication layer. AIT-GUI's HTTP endpoints — including those that change state and dispatch commands to instruments — accepted requests from any client. There was no login flow, no API token, no session mechanism to bypass because none existed.
- No session checks. Requests to command-dispatch endpoints were processed purely on reachability. If you could route to the service port, you were an operator.
- No CSRF protection. Because state-changing endpoints lacked anti-CSRF tokens, an attacker didn't even need direct network access in every scenario — a logged-in-by-default operator's browser could be weaponized. Any engineer browsing a malicious page while on the mission network could have their browser silently fire cross-origin requests at the AIT-GUI console, issuing commands on the attacker's behalf.
The practical attack chain is trivially short: scan for the AIT-GUI service (it listens on a predictable HTTP port by default), enumerate the command/telemetry endpoints from the public source code, and POST crafted command payloads. Because AIT is open source, the endpoint structure and command dictionary formats are public — the attacker has full documentation.
Exploitation requirements and status
- Requirements: Network reachability to the AIT-GUI HTTP listener, or a victim operator's browser on the same network (CSRF path).
- Complexity: Trivial. No memory corruption, no race conditions — just well-formed HTTP requests against documented open-source endpoints.
- Status: Reported by Cycode as a research disclosure. No confirmed in-the-wild exploitation has been reported at time of writing, and it does not currently appear in CISA's KEV catalog. Treat this as a pre-exploitation window: the barrier to weaponization is effectively zero, and ground systems are increasingly within scope of nation-state and criminal reconnaissance. Internet-facing OT and research infrastructure is scanned continuously; any AIT-GUI instance exposed to a routable network should be assumed enumerated.
Detection & Response
Because AIT-GUI is a Python web service, the highest-fidelity detections live in web access logs, network flow, and process behavior on the hosting system. The rules below assume you are shipping AIT-GUI access logs (or upstream proxy/firewall logs) to your SIEM — if you are not, that gap is your first remediation item.
YAML
---
title: Unauthenticated HTTP Requests to AIT-GUI Command Endpoints
id: 3c9e2a41-7b6d-4f1e-9a52-8d4c6e0b1f23
status: experimental
description: Detects state-changing HTTP requests (POST/PUT/DELETE) against AIT-GUI operator console endpoints. In a hardened deployment, all such requests should arrive via an authenticated reverse proxy; direct hits indicate unauthenticated access attempts consistent with the CVSS 9.4 missing-authentication flaw in NASA/JPL AIT-GUI.
references:
- https://securityaffairs.com/197689/hacking/critical-flaw-in-nasa-jpl-open-source-spacecraft-command-software.html
- https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.initial_access
- attack.t1190
logsource:
category: webserver
product: linux
detection:
selection_method:
cs-method:
- 'POST'
- 'PUT'
- 'DELETE'
selection_endpoint:
cs-uri-stem|contains:
- '/cmd'
- '/command'
- '/api'
- '/tlm'
filter_authorized_proxy:
c-ip|startswith:
- '10.'
- '192.168.'
condition: selection_method and selection_endpoint and not filter_authorized_proxy
falsepositives:
- Legitimate operator traffic from untracked engineering subnets; baseline source IPs of known operator workstations and tune the filter
level: high
---
title: AIT-GUI Python Process Spawning Unexpected Child Processes
id: 8b1d4f72-2c5a-4e8b-b6d1-9f3a7c0e5d28
status: experimental
description: Detects the AIT-GUI web service process (python running ait/gui modules) spawning shells or system utilities. Command-dispatch consoles should never execute local shells; this behavior indicates possible post-exploitation or abuse of instrument command paths on the ground station host.
references:
- https://securityaffairs.com/197689/hacking/critical-flaw-in-nasa-jpl-open-source-spacecraft-command-software.html
- https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.execution
- attack.t1059
logsource:
category: process_creation
product: linux
detection:
selection_parent:
ParentCommandLine|contains:
- 'ait_gui'
- 'ait-gui'
- 'ait.gui'
selection_child:
CommandLine|contains:
- '/bin/sh'
- '/bin/bash'
- 'curl'
- 'wget'
- 'nc '
- 'python -c'
condition: selection_parent and selection_child
falsepositives:
- Custom AIT plugins that legitimately invoke local scripts; inventory and allowlist per-deployment
level: critical
---
title: Network Connection to AIT-GUI Listener From Unexpected Source
id: 5f2a8c14-9d3b-4e6f-a1c7-2b8e0d4f6a91
status: experimental
description: Detects inbound network connections to the AIT-GUI HTTP service from source addresses outside the approved operator segment. Ground system consoles should only be reachable from hardened jump hosts or the engineering VLAN.
references:
- https://securityaffairs.com/197689/hacking/critical-flaw-in-nasa-jpl-open-source-spacecraft-command-software.html
- https://attack.mitre.org/techniques/T1021/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.lateral_movement
- attack.t1021
logsource:
category: network_connection
product: linux
detection:
selection:
DestinationPort:
- 8080
Image|contains:
- 'python'
filter_approved:
SourceIp|startswith:
- '10.10.'
condition: selection and not filter_approved
falsepositives:
- Legitimate access from unmapped operator subnets; replace the filter prefix with your actual operator VLAN before deployment
level: high
KQL — Microsoft Sentinel / Defender
// Hunt for state-changing HTTP requests against AIT-GUI consoles ingested via CEF/Syslog.
// Tune the AllowedSources list to your engineering/operator subnets. Any hit outside that
// list represents unauthenticated access to a command-capable console (CVSS 9.4 exposure).
let AllowedSources = dynamic(["10.10.", "192.168.50."]); // replace with your operator VLANs
let StateChangeMethods = dynamic(["POST", "PUT", "DELETE"]);
union isfuzzy=true
(CommonSecurityLog
| where DeviceVendor =~ "AIT" or RequestURL has_any ("/cmd", "/command", "/api", "/tlm")
| where RequestMethod in~ (StateChangeMethods)
| where not (SourceIP has_any (AllowedSources))
| project TimeGenerated, SourceIP, SourcePort, DestinationIP, DestinationPort,
RequestMethod, RequestURL, DeviceAction, _ResourceId),
(Syslog
| where SyslogMessage has_any ("/cmd", "/command", "/ait")
and SyslogMessage has_any ("POST", "PUT", "DELETE")
| project TimeGenerated, Computer, ProcessName, SyslogMessage, _ResourceId)
| summarize Hits = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
by SourceIP, RequestMethod, RequestURL
| order by Hits desc
VQL — Velociraptor
-- Artifact: Windows/Linux hunt for exposed AIT-GUI listeners and their connection sources.
-- Identifies python processes bound to the AIT-GUI console port and any remote peers,
-- so responders can determine whether an unauthenticated console was reached and by whom.
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)ait.gui|ait_gui|ait-gui'
-- Correlate with live sockets: find the listener and its established peers
SELECT Pid, Name, LocalAddr, LocalPort, RemoteAddr, RemotePort, State
FROM netstat()
WHERE (LocalPort = 8080 AND State =~ '(?i)LISTEN')
OR (Name =~ '(?i)python' AND RemotePort > 0 AND NOT RemoteAddr =~ '^(127\\.|10\\.10\\.)')
Bash / Shell
#!/bin/bash
# ait_gui_exposure_check.sh — Verify and harden NASA/JPL AIT-GUI deployments
# Run on the ground-station host (or via your config management across all of them).
set -euo pipefail
echo "=== [1/4] Checking for running AIT-GUI processes ==="
ps aux | grep -Ei 'ait.gui|ait_gui' | grep -v grep || echo "No AIT-GUI process found."
echo "=== [2/4] Checking installed AIT version ==="
python3 -m pip show ait-gui 2>/dev/null | grep -E '^(Name|Version)' || \
echo "ait-gui not installed via pip on this host."
echo "=== [3/4] Checking listener exposure (is it bound to 0.0.0.0?) ==="
if ss -tlnp 2>/dev/null | grep -E ':(8080)\b'; then
echo "[!] AIT-GUI port is listening. Verifying bind address..."
ss -tlnp | grep -E ':8080\b' | grep '0.0.0.0' && \
echo "[CRITICAL] Bound to 0.0.0.0 — reachable from any network. Restrict immediately." || \
echo "[OK] Bound to loopback only."
else
echo "No listener on the default AIT-GUI port."
fi
echo "=== [4/4] Applying host firewall restrictions (operator subnet only) ==="
OPERATOR_SUBNET="10.10.0.0/16" # <-- set to YOUR operator/engineering VLAN
sudo iptables -C INPUT -p tcp --dport 8080 -s "$OPERATOR_SUBNET" -j ACCEPT 2>/dev/null || \
sudo iptables -I INPUT -p tcp --dport 8080 -s "$OPERATOR_SUBNET" -j ACCEPT
sudo iptables -C INPUT -p tcp --dport 8080 -j DROP 2>/dev/null || \
sudo iptables -I INPUT -p tcp --dport 8080 -j DROP
echo "Firewall: port 8080 now restricted to $OPERATOR_SUBNET."
echo ""
echo "NEXT STEPS:"
echo " 1. Update AIT/ait-gui: python3 -m pip install --upgrade ait-gui"
echo " 2. Place the console behind an authenticating reverse proxy (mTLS or SSO)."
echo " 3. Pull the last 90 days of access logs and audit for unauthenticated POSTs."
Remediation
Immediate (today):
- Inventory and isolate. Find every AIT-GUI instance in your environment — including lab VMs, test benches, and developer laptops running the toolkit for evaluation. Until patched, bind the service to loopback only (
127.0.0.1) and require access via an SSH tunnel or hardened jump host. - Network segmentation. Ground system consoles belong on a dedicated, access-controlled segment reachable only from designated operator workstations. Enforce this at the firewall, not by convention. No AIT-GUI listener should ever be reachable from a general user VLAN, and absolutely not from the internet — run an external scan of your ranges now to confirm.
Short term (this week):
- Update the toolkit. Pull the latest release of the AMMOS Instrument Toolkit from the NASA-AMMOS GitHub organization and the AIT documentation. Review the project's security advisories and the Cycode disclosure for the patched release addressing authentication on state-changing endpoints, then upgrade and re-test.
- Compensating controls where patching lags. If you cannot upgrade immediately, terminate all AIT-GUI traffic behind an authenticating reverse proxy (nginx/Apache with SSO or mTLS, or an identity-aware proxy such as oauth2-proxy/Pomerium). The proxy enforces the authentication the application lacks — this directly closes both the unauthenticated-access and the CSRF paths (cross-origin requests won't carry proxy credentials by default).
Structural (this quarter):
- Audit historical access. Export 90+ days of web/proxy/firewall logs for every console and hunt for POST/PUT/DELETE requests from sources outside your operator population (the KQL query above is your starting point). A missing-authentication flaw leaves no exploitation artifacts on the host — log review is your only retroactive lens.
- Fix the pattern, not just the product. Add "does this tool ship with authentication enabled by default?" to your procurement and open-source intake checklist. Engineering and OT tooling is chronically exempted from application-security review; this incident demonstrates exactly why it should not be. Require CSRF tokens and authentication on all state-changing endpoints for any internally developed console, and verify with an authenticated vs. unauthenticated scan (your DAST tool of choice) before deployment.
- Monitor going forward. Deploy the Sigma rules above to any sensor covering ground-station or engineering-segment hosts, and alert on any new HTTP listener appearing in that segment — shadow consoles are a recurring problem in research environments.
The uncomfortable truth of this disclosure is that the "exploit" is an HTTP request. Defenses against that are not exotic: authentication, segmentation, and logging. Organizations that treat ground and engineering systems with the same rigor as their corporate IT estate will shrug this off. Everyone else should use this window — before exploitation is confirmed in the wild — to close the gap.
Related Resources
Security Arsenal Red Team Services AlertMonitor Platform Book a SOC Assessment pen-testing Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.