NASA's fprime-gds, the ground software used to command spacecraft built on the Jet Propulsion Laboratory's open source F Prime flight framework, shipped for years without checking who was sending it commands. GitHub Security Advisory GHSA-p6w2-c4j5-7xhm, published August 10, 2026, rates the flaw CVSS 9.8 out of 10 and tracks it as CVE-2026-72577.
What the advisory found
The advisory describes the Flask application that serves fprime-gds's browser interface, at src/fprime_gds/flask/app.py, as applying no authentication to any endpoint. An attacker who can reach the server over a network, whether a lab subnet, a misconfigured VPN, or the open internet, can read telemetry, browse the full command dictionary, and according to the advisory achieve arbitrary code execution on the ground station host while injecting commands into a connected spacecraft. The weakness is classed as CWE-306, missing authentication for a critical function, and covers every fprime-gds release through version 3.4.3. Vulnerability aggregators tracking the same advisory also describe a path traversal flaw in the project's file upload handler, updown.py, capable of writing files outside the directory set aside for uplink files.
What F Prime actually flies
F Prime began as an internal JPL tool in 2013 and reached GitHub as a public open source project in 2017, structured around small reusable components wired together through typed ports rather than one large codebase. Its best-known flight was the Ingenuity Mars Helicopter, which completed 72 flights before NASA grounded it for good in January 2024 after its rotor blades suffered damage on landing. University labs and CubeSat and SmallSat teams have adopted the framework since, often running their own ground systems with only a handful of engineers and no dedicated security staff. The F Prime GitHub repository lists adopters ranging from NASA centers to Georgia Tech and other university programs, a spread that puts the same ground software behind missions with very different budgets for cybersecurity.
fprime-gds is the companion piece: a Python application with a browser GUI for sending commands, running sequences, and charting telemetry, built on a REST API that talks to the spacecraft's flight software. It was designed mainly as a development and integration tool, yet many small missions run it operationally once they reach orbit, on the same laptops and lab networks used to build and test the spacecraft in the first place.
The key is 0xfeedcafe
fprime-gds does check one thing before it issues a command, just not identity. Its command and sequence endpoints each require a field called "key," and the backend code accepts exactly one value: the literal constant 0xfeedcafe. A review of the project's public GitHub repository shows that same hexadecimal string hardcoded in the Python handlers commands.py and sequence.py, and duplicated in the browser-side JavaScript that assembles each request, addon.js and command-input.js. The docstring in commands.py spells it out as the expected payload: "key": "0xfeedcafe". The value never changes between installations and sits in plain text in code any browser downloads. It was built to stop an operator from issuing a command by accident, not to stop a stranger from issuing one on purpose. By contrast, the file-upload code in updown.py does run uploaded filenames through Werkzeug's secure_filename function, a narrower safeguard that the command and sequence endpoints never got.
Still unauthenticated months later
fprime-gds has shipped several releases since the advisory, with GitHub tags reaching v4.4.1 by late October 2026. A direct look at the project's main branch, at the commit dated October 27, 2026, shows its Flask module still has no login check, no session handling, and no token validation anywhere in the code, close to three months after the advisory went public. No NASA or JPL security bulletin naming CVE-2026-72577 turned up in this research, and no changelog entry describes an authentication fix landing. That leaves the people running fprime-gds to supply their own network controls rather than lean on anything the software enforces by default. This is a separate piece of NASA ground software from AIT-GUI, the AMMOS Instrument Toolkit console CYSAT covered after its own second security fix in October; the two share no code.
Why ground segment keeps failing this way
Kaspersky's ICS CERT, presenting at GISEC 2026, flagged internet-facing ground control systems and GNSS receivers as the parts of space infrastructure most overdue for an audit, and pointed back to the 2022 Viasat KA-SAT breach as the pattern to watch: attackers reached tens of thousands of satellite modems across Europe by compromising a misconfigured VPN appliance on the ground, never touching a satellite directly.
The Aerospace Corporation's SPARTA framework lists ground segment defenses as a standing countermeasure category for the same reason: ground infrastructure typically rides on ordinary IP networks, open to the phishing and credential theft that hit any enterprise.
For teams that cannot wait on an upstream fix, the practical mitigation looks less like a patch and more like basic network hygiene: keep the fprime-gds Flask port off any interface reachable from outside the lab, put a reverse proxy with its own login in front of it if remote access is needed, and treat any CubeSat ground station built on the framework as internet-facing until proven otherwise. fprime-gds adds a smaller, more specific version of the ground segment lesson, one hexadecimal string sitting in open-source code that students, university labs, and flight teams install by default, and it is the kind of detail a network scan would catch well before any attacker needs to.
First documented in the GitHub Security Advisory GHSA-p6w2-c4j5-7xhm, published August 10, 2026.
