NASA Spacecraft Control Software Has a Critical Flaw Attackers Could Use Remotely
Researchers at Cycode found a chain of bugs in AIT-GUI, a NASA/JPL tool used to talk to spacecraft, that lets outsiders send commands with no login required.
Key points
- Researchers at Cycode disclosed a critical flaw chain in AIT-GUI, the browser console for NASA/JPL's AMMOS Instrument Toolkit.
- The bug chain is tracked as GHSA-p9r8-2q67-fp86 and scores 9.4 out of 10 on the industry severity scale.
- An attacker who can reach the console over the network needs no username or password to send commands.
- The affected software is used by NASA's Jet Propulsion Laboratory to talk to spacecraft and scientific instruments during testing and operations.
- Operators should update AIT-GUI and restrict network access to the console.
A piece of NASA software used to send commands to spacecraft has a critical security hole. Anyone who can reach the tool over a network could fire off commands without logging in first.
That's the finding from researchers at Cycode, first reported by The Hacker News. The bug lives inside AIT-GUI, the web-based operator console for the AMMOS Instrument Toolkit, an open-source kit that NASA's Jet Propulsion Laboratory publishes so mission teams can build ground software for satellites and instruments. It's the second NASA open-source tool with a serious remote-exploitation flaw we've reported in six weeks: on 30 July we covered a flaw in NASA's Core Flight System that can crash spacecraft software.
In plain terms: AIT-GUI is the dashboard an operator opens in a browser to instruct a spacecraft. Point the antenna. Run a calibration. The researchers found a way to skip the operator entirely.
What did the researchers actually find?
Cycode chained several weaknesses in AIT-GUI so that an unauthenticated attacker, someone with no account and no password, can push arbitrary commands onto the software's command bus, the internal pipe that carries instructions to the spacecraft or instrument at the other end.
The chain is tracked as GHSA-p9r8-2q67-fp86 and rated 9.4 on the CVSS v3.1 scale, where 10 is the worst possible score. Most security teams treat anything above 9 as an emergency.
The failure mode is the classic one for lab-grown operator tools: the console assumes it's sitting on a trusted network where anyone who can reach it belongs there. That assumption breaks the moment the console is exposed to a broader network or a misconfigured VPN.
| Item | Detail |
|---|---|
| Affected software | AIT-GUI (AMMOS Instrument Toolkit) |
| Advisory ID | GHSA-p9r8-2q67-fp86 |
| Severity score | 9.4 / 10 (CVSS v3.1) |
| Authentication needed | None |
| Impact | Attacker can send arbitrary commands to the spacecraft/instrument command bus |
Should the public be worried about their satellites?
Not directly, and not today. AIT-GUI is a ground-side tool used inside mission control networks and test labs, not something reachable from the open internet by design. The realistic risk is an attacker already inside a mission network, through phishing or a compromised laptop, using this bug to jump from "on the network" to "sending spacecraft commands".
That's still serious. Ground software is downstream of the same everyday security failures that hit every other organisation.
What should operators do now?
Update AIT-GUI to the patched release listed in the GitHub advisory, then audit which machines can actually reach the console. If the operator dashboard is answering HTTP requests from outside a locked-down control segment, that's the first thing to fix, before the patch.
If this is ever abused, the post-mortem will say the console was reachable from a network it never should have been on. Patch the tool, but treat every "internal-only" web console as internet-facing until a firewall rule proves otherwise.
