Burning, Trashing, Spacecraft Crashing: A Collection of Vulnerabilities That Will End Your Space Mission

by Mileno Star, Andrzej Olchawa

Day 1 · Briefings · Exploit Development · 24 min · 4 min read

Offensive Security Network & Infrastructure

TL;DR

VisionSpace researchers Mileno Star and Andrzej Olchawa demonstrated three live exploits: an XSS in YAMCS that fires spacecraft telecommands silently, an XSS in OpenC3 Cosmos that yields a reverse shell on the mission control server, and a GOT overwrite through NASA CFS's memory management module that returns code execution on the spacecraft itself. Across five audited open-source platforms, they also catalogued prototype pollution, arbitrary file deletion, unauthenticated crash-and-key-reset, and RCE paths. The space industry is 99.9% closed software. None of it has been reviewed.

Why Space Systems Are Newly Exposed

▶ Watch (00:50)

Cold War satellite launches slowed by the 2000s, then commercial constellations like Starlink reversed that trend sharply. Now thousands of satellites are in low Earth orbit, Starlink terminals are on the front lines in Ukraine, and governments are relaunching intelligence-gathering missions. More assets, more operators connecting remotely over VPN, and systems originally built for perimeter-controlled networks now exposed directly to the internet. That combination produces a very large attack surface against very high-value targets.

The Software Stack That Controls Spacecraft

▶ Watch (04:51)

Mission control centers run custom IT infrastructure: astrodynamics software, mission planning tools, and human-machine interfaces that spacecraft operators use to send commands. The researchers picked three popular open-source platforms: YAMCS (used on the ISS European Robotic Arm and being planned for lunar rovers), NASA’s Open MCT (used to control Mars rovers), and OpenC3 Cosmos. On the spacecraft side they targeted NASA’s Core Flight System, which powers James Webb Telescope payloads and is being qualified for the Lunar Gateway, plus F-Prime (Ingenuity Mars helicopter) and AIT-CORE. None were designed with internet-exposure in mind.

XSS to Spacecraft Telecommand via YAMCS

▶ Watch (08:22)

YAMCS lets operators define engineering values using JavaScript, and that scripting component does not sanitize HTML tags. A payload embedded in an HTML attribute executes silently: the UI hides the tags entirely, so the operator sees nothing suspicious in the code. In the YAMCS XSS telecommand demo (11:20), Olchawa phished an operator with a script file. Once opened, the XSS fired a telecommand through the YAMCS API on the operator’s behalf, triggering an orbit-transition maneuver. The spacecraft moved. The only indication was a new entry in the command history.

XSS to Remote Code Execution via OpenC3 Cosmos

▶ Watch (12:48)

OpenC3 Cosmos also carries an XSS, but exploiting it requires three back-end API calls: grab the session token, deploy the malicious script, then trigger it. A helper script generates the phishing URL automatically. In the OpenC3 Cosmos reverse shell demo (13:22), an operator visits the URL, sees the mission control UI load normally, and the attacker receives a reverse shell on the server running Cosmos. The entire mission control system, including its script-running engine, is now under attacker control.

Memory Exploit to Spacecraft Shell via NASA CFS

▶ Watch (16:03)

NASA CFS’s memory management module lets telecommands read and write memory anywhere in the process, not just within the module’s own allocation. CFS runs on Linux, so the global offset table is reachable. The attack: send telecoms to leak libc addresses, dump spacecraft memory to find the address of a target function (memchr), then overwrite that GOT entry with the address of system(). In the NASA CFS GOT overwrite demo (19:02), the script completes the leak, overwrites the table, and returns a reverse shell directly on the spacecraft platform.

Scope of Findings and What the Industry Must Fix

▶ Watch (20:28)

Beyond the demos, the team found prototype pollution in Open MCT, arbitrary file deletion in YAMCS, and container takeover in OpenC3. CFS’s cryptographic plugin (cryptolib) crashes entirely on an unauthenticated packet, then resets all keys to all-zeros on reboot if misconfigured. F-Prime and AIT-CORE also carry RCE paths. After the research was published, other teams found additional cryptolib issues: authentication bypass and a method to corrupt the spacecraft’s keystore. As Star put it, “the space industry is 99.9% closed software.” The bugs in open-source tools are just the visible fraction.

Notable Quotes

space security doesn’t has to be hard. Mileno Star · ▶ 24:00

So with that to say that water is wet Mileno Star · ▶ 24:11

Key Takeaways

XSS vulnerabilities in YAMCS and OpenC3 Cosmos let attackers send spacecraft commands or gain server RCE.
NASA CFS’s memory management module allows arbitrary read/write across the entire flight software process.
99.9% of space software is closed-source and has never been publicly audited for these classes of vulnerability.

Filed under

Offensive Security Network & Infrastructure