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 are urged to 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 is 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 the ground software that talks to satellites, rovers and scientific instruments.
In plain terms: AIT-GUI is the dashboard an operator opens in a browser to send a spacecraft an instruction. Point the antenna. Turn a camera on. Run a calibration. The researchers found a way to skip the operator entirely.
What did the researchers actually find?
Cycode chained together several weaknesses in AIT-GUI so that an unauthenticated attacker, meaning someone with no account and no password, can push arbitrary commands onto the software's command bus. The command bus is the internal pipe that carries instructions to the spacecraft or instrument on 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. Anything above 9 is treated as an emergency by most security teams.
In practice, the failure mode here is the classic one for lab-grown operator tools: the console assumes it is sitting on a trusted, isolated network and that anyone who can reach it is already meant to be there. That assumption breaks the moment the console is exposed to a wider network, a jump host, 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 who is already inside a mission network, through phishing (fake emails that trick staff into handing over passwords) or a compromised laptop, using this bug to jump from "on the network" to "sending spacecraft commands".
That is still a serious risk. 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, and audit which machines can actually reach the console. If the operator dashboard is answering HTTP requests from anywhere outside a locked-down control segment, that is the first thing to fix, before the patch.
One thing the post-mortem will say, if this is ever abused: the console was reachable from a network it never should have been on.
Operational takeaway: patch the tool, but treat every "internal-only" web console as internet-facing until a firewall rule proves otherwise.
