A critical vulnerability in AIT-GUI, the browser-based operator console for NASA's open-source AMMOS Instrument Toolkit, allows unauthenticated attackers to issue spacecraft and instrument commands, execute server-side scripts and run command sequences [s1c1]. It is tracked as GHSA-p9r8-2q67-fp86, rated CVSS 9.4, affects all versions through 2.5.1, and had no CVE assigned at the time of reporting [s1c3].
AIT-GUI is the front end for an open-source framework for ground data systems that talk to instruments and spacecraft [s1c2]. So the exposure is not a dashboard defacement problem. The failures are the ordinary ones. AIT-GUI starts its web server on all network interfaces instead of honoring its configured host setting, and the API has no authentication, no authorization and no CSRF protection on state-changing endpoints [s1c5].
From there the routes speak for themselves. The /cmd route can relay commands to the command bus, while /script/run and /seq can execute scripts and command sequences [s1c6]. Those last two build filesystem paths from user-controlled input without adequate confinement, so files outside the intended directories can be passed for execution [s1c7]. A misbound listener plus no auth plus path traversal into an executor is the whole chain, and none of the three links is exotic.
The part operators should sit with is the delivery method. According to Cycode, direct network access to the AIT-GUI server is not necessarily required: because the state-changing routes accept browser-compatible form submissions with no CSRF protection, a malicious website visited by an operator can send the requests [s1c8]. Cycode said it demonstrated that an operator using a host-local or firewalled deployment could be targeted through their browser, with cross-origin requests delivered without a CORS preflight [s1c9]. That is the standard mitigation for this class of console -- keep it on localhost, keep it behind the firewall -- and it does not hold here.
Cycode researcher Yuval Elbar disclosed the findings on August 18, and the flaw is fixed in AIT-GUI 2.5.2 [s1c4]. Because the vulnerable range covers everything up to and including 2.5.1, there is no earlier safe build to fall back to [1]. The project's recommendations are authentication and authorization on state-changing endpoints, CSRF protection, binding the server to its configured host, and path confinement for the affected routes [s1c10]. Anyone who forked, vendored or embedded AIT-GUI in a derived ground system inherits all four items as work, not as a version bump.
Two things to watch. First, whether a CVE is issued: as of the reporting there was none [s1c3], which means inventory and scanning workflows keyed to CVE identifiers rather than GitHub advisories will not surface this on their own, and the search has to be done by hand against 2.5.1 and earlier. Second, whether NASA or JPL says anything about deployment scope. Infosecurity Magazine said it had contacted NASA/JPL for comment and would update with any response [s1c11]. Until then, the useful assumption for anyone running AMMOS-derived ground software is that an operator workstation with a browser is in the blast radius, and that patching to 2.5.2 is the floor rather than the fix.
