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

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

Speakers: Milenko Starcic (Head of Cybersecurity, Vision Space) and Andrej (Security Researcher, Vision Space; former European Space Agency)

Conference: Black Hat USA 2025 — August 6-7, 2025, Mandalay Bay, Las Vegas

YouTube: https://www.youtube.com/watch?v=uLZab4pe4X0

Reading time: 8 minutes

Type: Briefing

TL;DR

Researchers from Vision Space demonstrated live exploits against three open-source mission control systems and NASA's Core Flight System, proving that software vulnerabilities — not kinetic weapons — are now the most accessible path to destroying a satellite mission. Critical flaws including XSS-to-telecommand injection, remote code execution, and an unauthenticated crash-and-key-reset vulnerability were found across every system examined.

Introduction

Shooting down a satellite used to require a rocket. During the Cold War, the United States, Russia, China, and India all invested heavily in kinetic anti-satellite (ASAT) capabilities — expensive, politically explosive, and technically demanding. But as Milenko Starcic and Andrej of Vision Space argued at Black Hat USA 2025, a nation-state or sophisticated attacker no longer needs any of that.

The commercial space boom — driven by constellation operators like Starlink and OneWeb — has dramatically expanded both the number of satellites in orbit and the attack surface around them. Ground control systems, once protected by physical perimeters and air gaps, are now internet-facing. Operators work remotely. Open-source mission software runs on everything from small satellites to payloads aboard the James Webb Space Telescope. The result, as the researchers showed in three live demos, is that a chain of software vulnerabilities can take down a space mission from a laptop.

▶ Watch: Introduction and Space System Attack Surface (00:00)

The Architecture of a Space Mission — and Its Weak Points

To understand where the vulnerabilities live, the researchers walked through how a modern space system is structured. At the top level, a spacecraft (or constellation of many) communicates over radio frequency links with a ground station network. That network feeds into a mission control center, which handles telemetry display, mission planning, and sending telecommands back up to the spacecraft. Downstream, science data centers process the mission's outputs.

The mission control center is the heart of the operation, staffed by human operators around the clock. It relies on a stack of custom and open-source software: astrodynamics tools to track orbital position, mission planning software, and the mission control system (MCS) itself — the human-machine interface through which operators actually command the spacecraft.

Starcic noted a critical shift since COVID: "Traditionally this parameter-based security is no longer the case, and the systems that have been built for this parameter-based security are now exposed to the internet and to new threats." Remote operations opened a new threat model that the software was never designed to resist.

The researchers targeted two categories of software with cross-mission reuse potential: ground-segment mission control systems (YAMCS, OpenC3 COSMOS, and NASA's Open MCT) and spacecraft onboard software frameworks (NASA's Core Flight System, F Prime, and IIT Core).

▶ Watch: Space System Architecture Overview (02:00)

Demo 1: XSS to Telecommand Injection in YAMCS

The first live demonstration targeted YAMCS, an open-source mission control system. The attack vector was a stored cross-site scripting (XSS) vulnerability in the system's scripting functionality. YAMCS allows operators to load and execute scripts — a useful operational feature that becomes a weapon when the file parser fails to sanitize HTML tags.

The attack scenario: an adversary sends a malicious script file to a spacecraft operator as part of an internal phishing campaign. When the operator loads the file in YAMCS, an embedded HTML payload executes silently in the browser. The JavaScript then calls the YAMCS API on behalf of the authenticated user to issue telecommands to the spacecraft.

In the demo, Andrej triggered an orbit transition maneuver — moving the simulated spacecraft from low Earth orbit to medium Earth orbit — without ever touching the command interface. The spacecraft's telemetry showed the deviation; the command history recorded the telecommand. The operator had no indication anything was wrong until the satellite moved.

"You can see the spacecraft started deviating from its original orbit," Andrej noted. "The only way for the user to know that this has happened is to either actually see that the spacecraft moved away using the telemetry, or in the command history."

▶ Watch: YAMCS XSS Demo (08:00)

Demo 2: Full RCE on OpenC3 COSMOS via XSS

The second demo escalated significantly. OpenC3 COSMOS, another open-source mission control system, also contained an XSS vulnerability — but the exploitation chain here yielded remote code execution on the system running the MCS.

The attack was multi-stage. The adversary first generates a malicious URL using a crafted script. When a phished operator visits that URL, the XSS payload executes a sequence of API calls: first grabbing session tokens, then deploying a malicious script through the system's script running engine, and finally triggering it. The net result is a reverse shell back to the attacker's system.

"Imagine I'm a user that fell for the phishing campaign. I went to the URL. I see my mission control system, which looks like nothing has happened," Andrej explained — then pointed to the terminal showing a live reverse shell on the OpenC3 host.

Beyond XSS, the researchers found higher-severity vulnerabilities across all three ground-segment systems: prototype pollution in NASA's Open MCT (JavaScript-based), arbitrary file deletion on the underlying operating system in YAMCS, and full container takeover via RCE in OpenC3 COSMOS.

▶ Watch: OpenC3 RCE Demo (12:00)

Demo 3: Direct Attack on a Spacecraft Running NASA's Core Flight System

The third and most technically sophisticated demonstration bypassed the ground segment entirely. The target was NASA's Core Flight System (CFS), an onboard software framework with over 20 years of history that powers small satellite missions and payloads on the James Webb Space Telescope, and is currently being qualified for human spaceflight on the Lunar Gateway.

The attack scenario assumed a nation-state with its own ground station and radio visibility to the target spacecraft. CFS's memory management module was the entry point. The module exposes a weakness that allows an attacker to read arbitrary memory addresses from the spacecraft via malicious telecommands — effectively turning it into a remote memory leak primitive.

The exploit chain worked as follows: the attacker's script communicated back and forth with the spacecraft via telecommands, first leaking memory addresses from libc to defeat address space layout randomization, then dumping the contents of specific memory regions to locate the address of the memchr function in the global offset table (GOT). With that address in hand, the script overwrote the GOT entry with the address of system, then triggered the function call — resulting in a reverse shell running on the spacecraft's onboard computer.

"What we found is that actually you can have a much easier time if you combine and chain some vulnerabilities you find in the software on ground or on the space segment to actually take down a space mission," Starcic said.

The researchers also found vulnerabilities in CryptoLib, a CFS plugin for encrypting telemetry and authenticating sessions. A critical flaw allowed an unauthenticated attacker to send a single malformed packet and crash the entire onboard software stack. On reboot, CryptoLib — if improperly configured — resets all its cryptographic keys, enabling an attacker to then inject their own keys and take over encrypted communications with the spacecraft.

▶ Watch: Core Flight System RCE Demo (16:05)

Scope of Findings

Across all systems examined, the research produced a significant catalog of vulnerabilities spanning all severity tiers. The researchers emphasized that every piece of software they assessed was open source — and that the space industry runs approximately 99.9% closed-source software.

"Our question is: what is to be found there?" Starcic asked.

Since publication, their findings attracted follow-on research from the broader community. Other researchers independently discovered additional CryptoLib weaknesses, including an authentication bypass that allows key database corruption and separate memory issues yielding additional high and critical CVEs.

The research also surfaced a systemic tension in space cybersecurity: the security-safety trade-off around authentication for spacecraft. Engineers are historically reluctant to add cryptographic authentication to command links because, unlike a datacenter, you cannot walk up to your satellite and recover it. Backup and override mechanisms are essential for mission continuity — but every override path is a potential attack vector.

▶ Watch: Summary of Findings and Final Thoughts (20:08)

Notable Quotes

"What traditionally meant, let's say in the '80s and '90s, destroying a satellite, was actually launching a rocket at it. But what we found is that actually you can have a much easier time if you combine and chain some vulnerabilities." — Milenko Starcic [06:00]

"Imagine I'm a user that fell for the phishing campaign. I went to the URL. I see my mission control system, which looks like nothing has happened." — Andrej [14:04]

"This was all found in open source software, and the space industry is 99.9% closed software. So our question is: what is to be found there?" — Milenko Starcic [22:09]

"You cannot fly up to your spacecraft and recover it easily — people are very cautious about adding too much security." — Milenko Starcic [22:09]

Key Takeaways

• XSS in mission control software is mission-critical: Vulnerabilities in YAMCS and OpenC3 COSMOS allowed adversaries to issue arbitrary telecommands and achieve RCE on ground infrastructure through phishing alone.
• NASA's Core Flight System contains exploitable memory weaknesses: A multi-stage GOT-overwrite attack against CFS produced remote code execution directly on spacecraft hardware — no kinetic capability required.
• CryptoLib's crash-and-reset vulnerability is particularly dangerous: An unauthenticated attacker can crash onboard software with a single packet, then inject their own keys into the reset crypto subsystem.
• The open-source attack surface is just the beginning: Every vulnerability found here was in publicly available software; the far larger closed-source ecosystem has never been systematically examined.
• Security-safety trade-offs need revisiting: The space industry's reluctance to add authentication overhead to command links — motivated by legitimate recovery concerns — creates exploitable gaps that adversaries can leverage remotely.

Slides

No slides PDF was available for this briefing.