Breaking
SecurityDeveloping Story

NASA ground control flaw opens door to unauthenticated commands

A critical AIT-GUI vulnerability could let attackers send commands to NASA spacecraft and instruments without authentication.

··2 hours ago·3 min read
turned-on black monitors
Photo by Nick Fewings on Unsplash

The browser-based console that NASA operators use to talk to spacecraft and scientific instruments has a serious hole in it. Researchers at Cycode found that the open-source AMMOS Instrument Toolkit (AIT)-GUI ground software carries a critical vulnerability that could allow unauthenticated attackers to issue commands to spacecraft and instruments, execute server-side scripts, and run command sequences. The flaw, tracked as GHSA-p9r8-2q67-fp86, carries a CVSS score of 9.4 and affects AIT-GUI versions through 2.5.1. No CVE has been assigned at the time of writing.

What AIT-GUI does

AIT-GUI is the browser-based operator console for NASA's AMMOS Instrument Toolkit, an open-source framework for ground data systems that communicate with instruments and spacecraft. The toolkit is used to monitor and control missions, handling everything from telemetry to command sequences.

Cycode researcher Yuval Elbar disclosed the findings on August 18, and the flaw has been fixed in AIT-GUI 2.5.2.

How the flaw works

The core problem is that AIT-GUI starts its web server on all network interfaces rather than honoring its configured host setting. That means the service might be reachable from outside the intended network boundary. On top of that, the API has no authentication, authorization, or cross-site request forgery (CSRF) protection on state-changing endpoints.

Specifically, the /cmd route can relay commands to the command bus, while /script/run and /seq can execute scripts and command sequences. The latter two endpoints also construct filesystem paths from user-controlled input without adequate confinement, allowing files outside the intended directories to be passed for execution.

Why it matters for mission control

The combination is significant because these web functions sit between an operator console and command infrastructure. Security weaknesses in exposed operational technology (OT) environments can similarly turn basic access-control failures into routes to high-impact functions.

This is not just a theoretical concern. The attack does not necessarily require direct network access to the AIT-GUI server. Because the state-changing routes accept browser-compatible form submissions without CSRF protection, a malicious website visited by an operator can send requests to the service.

Browser-based attack possible

Cycode said it demonstrated that an operator accessing a host-local or firewalled deployment could therefore be targeted through their browser, with cross-origin requests delivered without a CORS preflight. That means an operator doing routine work—checking telemetry, reviewing sequencer output—could be hit by a malicious site in another tab.

The attack path is not exotic. It works because the vulnerable endpoints treat any incoming request as legitimate, and the browser-based nature of AIT-GUI means the operator's own browser can become the vector.

What's been fixed

The project recommends authentication and authorization for state-changing endpoints, CSRF protection, binding the server to its configured host, and path confinement for the affected routes. The fix is in AIT-GUI 2.5.2, so operators should upgrade immediately if they haven't already.

Infosecurity Magazine has contacted NASA/JPL for comment and will update this article with any response.

What this means for space operations

This finding is a reminder that space missions depend on software that needs the same rigor as any other critical infrastructure. Mission operators should treat ground control software as high-value targets and ensure they're running patched versions, with network access restricted to those who need it.

The browser-based attack surface is particularly awkward: it means that even a well-intentioned operator, just by visiting the wrong website, could become the inadvertent conduit for a command injection. That's the kind of risk that argues for keeping such consoles on isolated networks and enforcing strict access controls.

The broader lesson is that open-source tools, no matter how trusted, need constant scrutiny. A single missing check can turn a mission-critical console into a liability.

#nasa#ait-gui#vulnerability#ground control#spacecraft security

Sources

Iliyas

Founder & Editor, Xploitwire

This article was compiled from the sources listed above and checked against them for accuracy, under editorial policies set by Iliyas. Read our Editorial Policy →

← Back to all stories