NASA F Prime GDS CVE-2026-72577: RCE in a ground control system

CVE-2026-72577, published on 10 August 2026, describes a critical flaw in NASA’s F Prime Ground Data System. Its Flask-based web application applies no authentication to endpoints, while file functions allow path traversal. According to the CNA record, an unauthenticated remote attacker may achieve code execution on the ground-station host and, when the system is connected to a vehicle, submit arbitrary commands through the available interface.

The issue scores 9.8 under CVSS 3.1: network access, low complexity, no privileges and no user interaction. It affects releases through 3.4.3. The record does not identify the first safe release and does not prove that a particular space mission was compromised. Teams should take the technical capability seriously without turning it into a claim about an incident that the sources do not establish.

What F Prime GDS does

F Prime GDS is the ground tooling for the F Prime flight framework. It receives telemetry, allows an operator to observe channels and events, manages files and passes commands to a flight system. In a test environment it may connect to a simulator or laboratory hardware; in operations it can form part of a trusted command path.

That distinction is essential to impact analysis. Code execution on an isolated test laptop is still a compromise, but its consequence differs from takeover of a host connected to a live command link. CVSS describes vulnerability potential, not the topology of a particular deployment. An organisation must determine which vehicle, simulator, segment and set of secrets each host could reach.

The command-handling code illustrates why this is not an ordinary dashboard. An endpoint can participate in initiating actions. The upload and download module operates on file paths. Combining the absence of an identity gate with unsafe path interpretation creates a route from an HTTP request to host resources.

Two boundaries failed

The first boundary is authentication. Before exposing telemetry, files or a command function, an application needs to know who issued the request. Restricting the port to an internal network is useful but does not replace identity: another device on that segment can be compromised and a publishing rule can change.

The second boundary is the filesystem root. When an endpoint accepts a filename, it should build the path relative to one approved directory, resolve it canonically and verify that the result remains under that root. Simply stripping ../ is fragile against encoding, separator variations and symbolic links. The process should also have operating-system rights only to directories it genuinely needs.

Missing authentication increases the reachability of the file flaw. Traversal may allow reading or writing outside the intended location, while writing to a file later interpreted by a process or launch mechanism can lead to RCE. The CNA describes the achievable result; exact mechanics depend on host configuration and process privileges.

Who is affected

Installations of fprime-gds through 3.4.3 are directly affected. The package is also distributed through PyPI, so inventory must cover Python virtual environments, container images, operator workstations, lab laptops and test automation. Looking only for a central server with “NASA” in its name will miss local dependency installations.

First priority is a host reachable from an untrusted network or attached to a real command channel. Second is a shared laboratory, university network or demonstration environment where many users can reach the Flask port. An offline test image has lower urgency, but it still needs removal or remediation before it returns to service.

Assess exposure from the perspective of network segments rather than the public Internet alone. An accidental port forward, developer tunnel, reverse proxy, contractor VPN or shared Wi-Fi can expose the service more broadly than its operator expects. Firewall history is as important as the configuration observed during the review.

Immediate response

1. Find every instance and record the effective package version and image digest.
2. Disconnect vulnerable services from untrusted networks. If a system controls active hardware, follow the applicable operational safety procedure.
3. Put access behind strong authentication, MFA and role controls; restrict sources at the firewall as an additional layer.
4. Obtain a project release that explicitly resolves the CVE and follow its guidance. The record does not support guessing a safe version number.
5. Run the process as a dedicated account without filesystem access beyond required directories and without unnecessary secrets.
6. Suspend direct command forwarding to an active target until the ground station’s integrity has been established.
7. Preserve reverse-proxy, host, EDR, firewall, configuration-repository and flight-system logs before rotation or rebuilding removes evidence.

If the service was reachable, inspect created and modified files, startup mechanisms, scheduled tasks, SSH keys, application command history and outbound connections. Compare the system with a trusted image. For a high-criticality station, rebuilding from controlled media can provide stronger assurance than manually deleting only the changes that were discovered.

Separate IT security from command authorization

Even after the application is fixed, high-impact commands should have independent safeguards. Options include state-based allow rules, two-person approval, cryptographic channel authentication, sequence constraints and a physical or logical inhibit. A web control plane should not be the sole trust boundary for an irreversible operation.

Monitoring should correlate three layers: a request to GDS, a host process or file change and the message delivered to the target. If only the application log exists, an attacker with RCE can alter it. An independent collector, command-link record and receiving-system telemetry make reconstruction possible. Clocks need synchronization, and the service account must not be able to rewrite the central records.

The same principle applies to factories, robotics and operational technology. Operator software often begins as a laboratory tool on a trusted network, then moves into service without a complete identity model. The assumption that “only our staff can see the port” can become the only control protecting a function with physical effects.

Validating remediation

After updating, confirm that no sensitive endpoint responds anonymously, sessions use secure attributes and roles restrict commands and files. Test encoded and absolute paths, mixed separators and symbolic links in an isolated environment. The canonical result must remain within the approved root, and the operating-system account must not write to executable locations.

Functional tests should also cover failure states. Loss of the identity provider must not silently open the panel, and a failed authorization must stop a command without leaving it queued. Logs should record operator identity, policy decision, command identifier and result without exposing secrets.

The authentication, traversal, version and potential command effects are facts from the CVE record. It does not report compromise of an operational spacecraft. Segmentation, dual authorization and log correlation are Breachroad recommendations based on the critical role of a GDS.

This case is valuable for a tabletop exercise: a team must distinguish vulnerability from incident while still making a safe decision under pressure. Our cybersecurity training for organisations covers that reasoning. Architectures with remote access and control functions can also benefit from an independent IT security assessment.